HTTP Status Code Lookup

What Is an HTTP Status Code?

Every HTTP response your browser or API client receives includes a three-digit status code a number the server uses to tell you what happened with the request. Developers see these constantly: in browser DevTools, in server logs, in API responses, and in error monitoring dashboards. Knowing what each one means and more importantly, knowing the difference between similar ones like 401 vs 403 or 301 vs 302 is one of those fundamentals that separates junior developers from senior ones.

The codes are grouped into five classes based on their first digit. 1xx codes are informational the server is acknowledging the request before the full response is ready. 2xx means success in some form. 3xx means redirection go somewhere else. 4xx means the client made an error. 5xx means the server failed, regardless of what the client sent. That first digit alone tells you 80% of what you need to know before looking up the specific code.

This tool covers all official codes defined in RFC 9110 the current HTTP semantics standard plus unofficial but widely-used codes like Cloudflare's 52x series, the infamous 418 I'm a Teapot, and WebDAV-specific codes that show up constantly in modern API work.

How to Use the HTTP Status Code Lookup Tool

The tool is designed for zero-friction lookup no form submission, no page reload, no account needed.

1. Search by number: Type 404 and the code appears instantly as you type.

2. Search by name: Type not found or forbidden the tool matches against official names.

3. Search by concept: Type redirect to see all 3xx codes, or auth to see 401 and 407 together.

4. Filter by category: Use the category buttons (1xx / 2xx / 3xx / 4xx / 5xx) to browse a full class at once.

5. View code details: Click any code card to see the full description, cacheability, retry safety, RFC reference, and JavaScript/Next.js handling examples.

6. Copy with one click: Copy the code number or the full 404 Not Found string for use in documentation or code.

Press / anywhere on the page to instantly focus the search bar a keyboard shortcut I added because I use this tool mid-coding without wanting to reach for the mouse.

Key Features

• Complete IANA coverage (100–599): Every officially registered HTTP status code, not just the common ones. WebDAV codes (207, 208, 422, 423, 424), deprecated codes (305, 306) with deprecation notices, and rarely-documented codes like 226 IM Used are all here.

• Cloudflare-specific codes: Cloudflare returns codes like 520 Unknown Error, 521 Web Server Is Down, 522 Connection Timed Out, and 524 A Timeout Occurred that aren't in the official HTTP spec. They show up constantly in production this tool explains each one.

• JavaScript and Next.js handling examples: Every code includes a fetch response handling snippet and a Next.js res.status() example. No other status code reference does this it's the gap I kept noticing when using other tools.

• Cacheability and retry safety flags: Each code shows whether responses with that status can be cached, and whether the request is safe to retry automatically critical for building resilient API clients.

• Confusion pair comparisons: 401 vs 403, 301 vs 302, 400 vs 422, 500 vs 502 vs 503 the pairs developers always confuse are linked to each other with direct comparison tables.

• Deep-linkable URLs: Every code gets its own shareable URL like /tools/http-status-code-lookup?code=404 useful for linking a specific code in a code review comment or Slack message.

• 100% client-side processing: The entire tool runs in your browser. No lookup requests are sent to any server search, filter, and copy all happen locally.

When Should You Use This Tool?

Every developer has a mental cache of HTTP codes that goes exactly as far as 200, 301, 404, and 500. Everything else gets looked up. Sound familiar? That's exactly the use case this tool is built for not as a course to read through, but as a reference you keep open in a pinned tab.

During API development: You're writing a REST endpoint and need to decide whether to return 400 or 422 for a validation error, or whether to use 401 or 403 for a permissions check. Open this tool, search both codes, read the comparison decision made in 30 seconds.

During debugging: You're reading server logs and see a 499 or a 520 codes that aren't in the standard HTTP spec. This tool covers unofficial and Cloudflare-specific codes that most references skip entirely.

During code review: A PR uses res.status(200) for a successful POST that created a resource. You know 201 is more correct, but you want to quickly confirm look it up, copy the deep link, drop it in the review comment.

During SEO or DevOps work: You're auditing redirect chains and need to confirm whether 307 or 308 preserves the HTTP method, or whether 410 tells Google to de-index faster than 404. This tool includes SEO implications for redirect and error codes. Pair it with our robots.txt and llms.txt generator for a complete technical SEO workflow.

The Confusion Pairs: 401 vs 403, 301 vs 302, 500 vs 502 vs 503

These are the codes that trip up even experienced developers. I've seen 401 and 403 used interchangeably in production APIs which is actually a security issue, not just a semantics one. Here's the definitive breakdown.

401 Unauthorized vs 403 Forbidden

This is the most commonly confused pair in web development. The names don't help "Unauthorized" sounds like it should mean "not allowed," but the HTTP spec uses it specifically to mean "not authenticated."

The security implication: returning 403 when you should return 401 tells attackers that the resource exists and that they're authenticated but lack permission information that might be useful to them. Use 401 when identity is the issue, 403 when permissions are the issue. Use our JWT decoder tool to inspect token claims and expiry useful when debugging whether a 401 is an expired token or an authentication flow issue.

301 Moved Permanently vs 302 Found (Temporary Redirect)

The practical rule: use 301 when you're migrating a URL permanently and want search engines to update their index. Use 302 for temporary situations like A/B tests, maintenance pages, or login-required redirects. Use 307/308 instead of 302/301 when your redirect involves non-GET requests and you need the HTTP method preserved.

500 Internal Server Error vs 502 Gateway vs 503 Service Unavailable

All three are server-side errors, but they mean very different things in production especially for DevOps and API monitoring.

For SEO: return 503 with a Retry-After header during planned maintenance this tells Googlebot to re-queue the page rather than de-index it. A 500 with no retry signal during a long outage can cause pages to drop from the index.

HTTP Status Codes in JavaScript - Handling Examples

Knowing what codes mean is half the work. The other half is handling them correctly in your application code. Here are the patterns I use in production Next.js and Node.js projects.

fetch API - Handling Common Status Codes

const response = await fetch('/api/users/123');

// fetch only throws on network errors — NOT on 4xx/5xx
// You must check response.ok or response.status manually
if (!response.ok) {
  switch (response.status) {
    case 400:
      throw new Error('Bad request — check your input data');
    case 401:
      // Token expired or missing — redirect to login
      window.location.href = '/login';
      break;
    case 403:
      // Authenticated but no permission — show access denied UI
      throw new Error('You do not have permission to view this');
    case 404:
      // Resource not found — show empty state, not error page
      return null;
    case 429:
      // Rate limited — respect Retry-After header
      const retryAfter = response.headers.get('Retry-After');
      throw new Error(`Rate limited. Retry after ${retryAfter}s`);
    case 500:
    case 502:
    case 503:
      // Server error — show generic error, log to Sentry
      throw new Error('Server error — please try again shortly');
    default:
      throw new Error(`Unexpected status: ${response.status}`);
  }
}

const data = await response.json();

Next.js Route Handler - Returning Status Codes Correctly

// app/api/users/[id]/route.ts
import { NextRequest, NextResponse } from 'next/server';

export async function GET(
  request: NextRequest,
  { params }: { params: { id: string } }
) {
  // 400 — validation failed before hitting the DB
  if (!params.id || isNaN(Number(params.id))) {
    return NextResponse.json(
      { error: 'Invalid user ID' },
      { status: 400 }
    );
  }

  const user = await db.users.findById(params.id);

  // 404 — resource not found
  if (!user) {
    return NextResponse.json(
      { error: 'User not found' },
      { status: 404 }
    );
  }

  // 200 — success with body (default for NextResponse.json)
  return NextResponse.json(user);
}

export async function POST(request: NextRequest) {
  const body = await request.json();
  const newUser = await db.users.create(body);

  // 201 — resource created (NOT 200 — more semantically correct)
  return NextResponse.json(newUser, { status: 201 });
}

Notice 201 Created on the POST handler most developers return 200 here out of habit, but 201 is the semantically correct code for resource creation. It should include a Location header pointing to the new resource. Small detail, but it matters when building public APIs that other developers will consume. For more on building type-safe APIs with correct status handling, see our guide on type-safe API validation with Zod and Next.js.

Common Mistakes Developers Make with HTTP Status Codes

• Returning 200 for errors: The classic mistake wrapping every response in a 200 with an error field in the JSON body. This breaks HTTP semantics, confuses monitoring tools, and makes client-side error handling unnecessarily complex. Return 4xx or 5xx when something went wrong that's what those codes exist for.

• Using 404 when 410 is more appropriate: If a resource has been intentionally deleted and will never return, use 410 Gone instead of 404. Google processes 410 faster for de-indexing a 404 might take weeks to remove from search results, while 410 is processed much more quickly.

• Returning 403 instead of 401 for unauthenticated requests: If the user hasn't logged in at all no token, no session return 401, not 403. The 401 response should include a WWW-Authenticate header telling the client how to authenticate. Returning 403 for unauthenticated users is a subtle security disclosure issue.

• Not including Retry-After on 429 and 503: When you return 429 Too Many Requests or 503 Service Unavailable, always include a Retry-After header. Without it, aggressive clients will hammer your server immediately with it, they back off automatically. This is both a performance concern and good API citizenship.

• Using 301 when you mean 302: If you're running an A/B test or a temporary campaign redirect, use 302 not 301. Browsers cache 301 responses aggressively, sometimes for months. A "temporary" redirect that was accidentally made permanent with 301 can cause hard-to-debug issues when you want to change the redirect destination.

Cloudflare-Specific Status Codes Explained

If you're running your site behind Cloudflare (and in 2026, most production sites are), you'll occasionally see status codes in the 520–527 range that aren't in the HTTP spec at all. These are Cloudflare's own error codes they originate from Cloudflare's edge, not your origin server.

• 520 Unknown Error: Cloudflare received an unexpected response from your origin. Usually means your origin server crashed or sent malformed HTTP.

• 521 Web Server Is Down: Cloudflare couldn't connect to your origin server at all origin is down or refusing connections on port 80/443.

• 522 Connection Timed Out: Cloudflare connected to your origin but the origin didn't respond within the timeout window (usually 90 seconds).

• 524 A Timeout Occurred: Cloudflare established a connection but your origin didn't send a complete response in time. Common with slow database queries or long-running server processes.

• 525 SSL Handshake Failed: Cloudflare couldn't complete the TLS handshake with your origin SSL certificate issue on the origin server.

• 526 Invalid SSL Certificate: Cloudflare reached your origin but the SSL certificate is invalid, expired, or self-signed when Cloudflare expects a valid cert.

• 527 Railgun Error: Cloudflare Railgun (legacy WAN optimization) connection failed mostly relevant for older Cloudflare setups.

When you see a 52x error in logs or monitoring, the issue is always between Cloudflare and your origin not between the user and Cloudflare. Check your origin server health, SSL configuration, and response times first.

Related Tools You Might Find Useful

If you're building or debugging APIs, these tools pair naturally with HTTP status code lookup:

• JWT Decoder and Verifier : When you're getting 401 errors and need to inspect your token's claims, expiry, and signature. Runs entirely client-side paste the token, see the decoded payload instantly.

• Regex Tester and Debugger : For validating URL patterns in route handlers or testing the regex in your error-handling middleware. Useful when building the routing layer that returns these status codes.

• Robots.txt and llms.txt Generator : Status codes 200, 301, 404, and 410 all affect how Googlebot and AI crawlers index your content. Pair with a well-configured robots.txt for complete crawl control.

Why Use WebToolsHub?

Every tool on WebToolsHub is completely free, runs entirely in your browser, and requires zero signup, zero installation, and zero account management. The HTTP Status Code Lookup tool stores nothing your searches, recently viewed codes, and any copied content all stay on your machine. No analytics events are fired on individual lookups, no search terms are logged to any server.

I built WebToolsHub because I was tired of tools that required an account to access a reference table, or loaded a 4MB JavaScript bundle just to display a list of status codes. Every tool here is built to be fast, focused, and genuinely useful in a real development workflow not to collect your email address.