HTTP Tools

HTTP is the conversation between a browser and a server, and most of what goes wrong on a website shows up in it: a page that returns the wrong status code, a redirect that loops, or an API that starts refusing requests under load. This category collects free references and calculators that make that conversation easy to read and plan for, whether you are fixing a live site or designing an API. Everything works in your browser, with no account and nothing stored.

HTTP status code lookup

The HTTP status code lookup is a searchable reference for every response code, from 200 OK to 503 Service Unavailable, with what each one means, which class it belongs to and when a server should send it. It is the quick answer when a crawler reports soft 404s, a payment provider returns 402, or you are deciding between a 301 and a 302 for a moved page.

API rate limit calculator

Rate limits protect an API from spikes without blocking legitimate users. The API rate limit calculator turns your expected traffic into requests per second, a per-window quota, a token-bucket size and a sensible Retry-After value, so you can set limits you can defend and give clients the headers they need to back off correctly when they receive a 429.

When these references help

Use them when search engines report crawl errors, when users see an unexpected error page, when you plan redirects for a redesign, or when an integration partner asks what limits and headers your API returns. Getting status codes and limits right keeps pages indexed, keeps clients from hammering your servers, and makes failures easier to diagnose.

Who they are for

Web developers and SEO specialists use the status code reference to choose the right response for every page, while backend and platform engineers use the calculator to size limits before launch. Product managers and support teams find both useful for explaining in plain words why a request failed and what the client should do next.

Common HTTP mistakes

A handful of habits cause most problems: returning 200 on a "not found" page, using a temporary 302 for a permanent move, chaining several redirects in a row, answering a rate-limited client without a Retry-After header, or sending 500 for a request that was simply invalid. Each one confuses browsers, crawlers or API clients, and each is easy to spot once you know which code belongs where.

Quick HTTP checklist

For every page, confirm it returns the status you intend: 200 for live content, 301 for permanent moves, 404 or 410 for pages that are gone. Keep redirects to a single hop, send Retry-After with every 429 and 503, and recheck after each deploy, because a single misconfigured rule can change thousands of URLs at once. Keep a short record of the results, so the next audit has a baseline to compare against and regressions stand out immediately.

Go deeper

Each page links to an in-depth guide on status codes, redirects, 404 versus 410, and rate limiting strategies, with examples you can apply to your own site or service straight away.

Tip: log the status code and the Retry-After header for every failed API call. Those two values usually explain the failure on their own and tell you exactly how long to wait before trying again. Keep a copy of the result so you can compare it after the next change. A 503 with Retry-After means wait and retry; a 4xx code usually means fix the request first.