HTTP Status Code Debugging Helper
Enter an HTTP status code and get a plain-English debugging checklist for APIs, websites, WordPress, webhooks, mobile apps and server errors. This tool helps you understand what codes like 400, 401, 403, 404, 422, 429, 500, 502 and 503 usually mean and what to check next.
- Understand the status family quickly.
- Get context-specific checks.
- Learn what not to waste time on.
- Create a clean report before asking for help.
Check an HTTP status code
Enter the code you received, choose where it happened, and add optional details. The helper will create a practical debugging report with likely causes, first checks, common mistakes and next steps.
Your HTTP status code debugging report will appear here. Enter a code such as 400, 401, 403, 404, 422, 429, 500, 502 or 503, then click Explain Status Code.
What this HTTP status code helper does
An HTTP status code is a short number returned by a server after a browser, app, crawler, API client or backend service makes a request. The code tells you whether the request succeeded, redirected, failed because of the client, or failed because of the server. The problem is that the number alone is rarely enough for beginners. A 401 does not simply mean “broken API.” A 403 does not always mean the password is wrong. A 404 can be a missing route, wrong API version, deleted resource, rewrite rule issue or a staging URL mistake. A 500 can be server code, hosting, database, plugin conflict, upstream timeout or a request that triggers a backend bug.
This tool turns a status code into a debugging path. Instead of giving a one-line definition, it combines the code with context such as browser app, Postman, WordPress, webhook, SEO crawl, backend server or mobile request. That context matters because the same status code can point to different checks. A 404 in a WordPress website may involve permalink rules, slug changes or missing posts. A 404 in a REST API may involve route spelling, API version or resource ID. A 429 from a public API usually means rate limiting, but a 429 from a login page may be abuse protection or repeated failed attempts.
The report generated by this page is meant to be copied into your own notes, support ticket, team chat or debugging checklist. It helps you collect the code, method, URL, context, likely meaning and first actions in a clean format. If your status code came from a URL with query parameters, use the CodeZips Query String Parser and Builder to inspect the parameters more carefully. If a parameter value contains spaces, symbols, redirect URLs or special characters, the CodeZips URL Encoder and Decoder can help you check whether the URL value is encoded correctly.
How to read HTTP status code families
Status codes are grouped by their first digit. That first digit gives you the fastest clue before you look at the exact code. A 2xx code usually means success. A 3xx code means the request is being redirected or the cached version can be used. A 4xx code means the server is saying something about the client request is not acceptable. A 5xx code means the server, gateway, hosting environment or upstream service failed while trying to handle the request.
| Status family | General meaning | Common debugging mindset |
|---|---|---|
| 1xx Informational | The server has received part of the request or is continuing the process. | Rarely the main issue for everyday website, WordPress or API debugging. |
| 2xx Success | The request succeeded, was accepted or returned no content. | If your app still fails, check response parsing, empty body handling or frontend assumptions. |
| 3xx Redirect | The requested resource moved, needs a different URL, or is using cache validation. | Check final URL, canonical URL, login redirects, HTTP to HTTPS, trailing slashes and redirect loops. |
| 4xx Client error | The server rejected the request because of syntax, auth, permissions, route, method, validation or rate limits. | Check the request first: method, URL, headers, token, permissions, parameters and body. |
| 5xx Server error | The server or upstream service failed while processing the request. | Check logs, hosting, gateway, timeout, deployment, plugin conflicts, database and provider status. |
The biggest beginner mistake is jumping straight to code changes without identifying the family. If you receive a 401, editing random JSON fields will usually not help because the problem is authentication. If you receive a 422, generating a new token will usually not help because the server already understood the request and rejected specific values. If you receive a 503, changing the button text in the frontend will not fix a service outage. Start with the status family, then use the exact code to choose the next check.
Common status codes and what to check first
| Code | What it usually means | Best first checks |
|---|---|---|
| 400 Bad Request | The server could not accept the request syntax, parameters, headers or body shape. | Check malformed JSON, wrong content type, invalid query values and missing required fields. |
| 401 Unauthorized | Authentication is missing, invalid, expired or sent in the wrong place. | Check bearer token, API key, session cookie, environment variable and authorization header format. |
| 403 Forbidden | The request was understood but the current user, token, app, origin or IP is not allowed. | Check permissions, scopes, role, plan limit, allowed origin, IP allowlist and organization access. |
| 404 Not Found | The route, resource, file, post, endpoint version or ID was not found. | Check path spelling, route registration, API version, permalink settings, deleted resources and environment. |
| 405 Method Not Allowed | The route exists but does not accept the method you used. | Check whether the endpoint expects GET, POST, PUT, PATCH or DELETE. |
| 409 Conflict | The request conflicts with the current state of the resource. | Check duplicate records, already processed actions, idempotency keys and version conflicts. |
| 415 Unsupported Media Type | The server does not accept the body format or content type you sent. | Check application/json, form data, file upload type, Accept header and documentation examples. |
| 422 Validation Error | The request was readable but failed field-level validation. | Check field names, enum values, dates, nested JSON, array format and required fields. |
| 429 Too Many Requests | The client hit a rate limit or abuse protection rule. | Stop rapid retries, check retry timing, reduce loops, batch requests and inspect background jobs. |
| 500 Internal Server Error | The server failed while processing the request. | Check logs, request ID, payload size, recent deployments, database errors and plugin conflicts. |
| 502 Bad Gateway | A gateway or proxy received a bad response from an upstream server. | Check reverse proxy, hosting, CDN, load balancer, upstream app and timeout settings. |
| 503 Service Unavailable | The service is temporarily unavailable, overloaded, down for maintenance or blocked by hosting limits. | Check provider status, hosting resource limits, maintenance mode, queue load and retry timing. |
| 504 Gateway Timeout | A gateway waited too long for the upstream service to respond. | Check slow database queries, long API calls, timeout limits, queues and upstream availability. |
HTTP status codes in API debugging
For APIs, the most useful information usually comes from combining the status code with the response body and headers. A code tells you the category, but the body may tell you the exact missing field, invalid token, expired session, route name or rate limit reason. If the body is JSON, you can paste it into the CodeZips JSON Formatter and Validator to make the structure easier to read before you debug. If the API uses query filters, pagination, sort fields or nested filter parameters, the CodeZips JSON to URL Query String Converter can help you understand how object-style filters become query parameters.
Authentication-related API errors often involve encoded tokens, JWT expiry times or URL-safe values. When a 401 or 403 response mentions a bearer token, scope, signature or expired credential, the CodeZips JWT Decoder can help you inspect non-secret JWT claims such as expiry and issuer. If the token or state value uses URL-safe Base64 characters, use the CodeZips Base64 URL-Safe Encoder and Decoder to understand the encoding format. For normal Base64 strings in headers, credentials or payload examples, the CodeZips Base64 Encoder and Decoder may be the better match.
Do not paste private tokens, passwords, session cookies or secret keys into public chats or support forums. If you need to share an error, remove secrets first and keep the status code, sanitized endpoint path, response body, timestamp, request ID and steps to reproduce. If the response includes Unix time values such as token expiry, rate-limit reset or event timestamp, the CodeZips Unix Timestamp Converter can help you check whether the time is actually expired or still valid.
HTTP status codes in WordPress and website debugging
On a normal website, status codes affect users, crawlers, analytics, redirects and link quality. A 404 on an old blog post might simply mean the post was deleted, but a 404 on every post can point to permalink rules. A 301 can be healthy when you intentionally moved a page, but redirect chains and loops can make debugging harder. A 500 on WordPress may come from a plugin conflict, PHP fatal error, theme issue, database connection problem, memory limit, hosting rule or broken custom code.
When you publish technical content in WordPress, be careful with visible code examples. If the article needs to show tags, JSON snippets, query strings or special characters, the browser may interpret them instead of displaying them. The CodeZips HTML Entity Encoder and Decoder is useful when you need code examples to display safely inside a WordPress article. If you are cleaning shared links or copied URLs before adding them to documentation, the CodeZips URL Parameter Cleaner can help remove tracking parameters that are not needed for the actual destination.
For SEO checks, remember that a status code is only one signal. A page that returns 200 can still have poor internal links, duplicate canonical signals, thin content or crawl priority issues. A page that returns 404 should usually be restored, redirected or intentionally left gone depending on whether it has value. A 410 tells crawlers that a resource is intentionally gone. A 503 can be safer than a 500 for short maintenance windows because it communicates temporary unavailability, but it should not remain active for long periods.
Examples of real debugging scenarios
Example 1: 401 in Postman
You send a GET request to an API profile endpoint and receive 401 Unauthorized. The body says the token is expired. The best first step is not to rewrite the endpoint. Check the authorization header, token expiry, selected Postman environment, bearer prefix and whether the token belongs to the same API environment. If the token is a JWT, inspect the expiry claim and compare the timestamp using a converter before assuming the API is down.
Example 2: 422 after submitting a form
Your frontend sends a POST request and receives 422 Validation Error. The request reached the server and the JSON was understood, but one or more fields failed validation. Check required fields, date formats, enum values, nested object shape and field names. If the response body contains an errors object, format the JSON and read the field-level details before changing anything else.
Example 3: 404 on a WordPress post
A WordPress post appears in the admin area but returns 404 on the public page. This can happen after permalink changes, slug changes, rewrite rule issues, cache problems or plugin conflicts. Save permalinks again, check the exact slug, clear cache and compare the public URL with the URL WordPress shows in the editor. If every post returns 404 but the homepage works, permalink rules are more suspicious than the individual post.
Example 4: 502 from an API behind a proxy
A frontend app receives 502 Bad Gateway from an API route. This often means the gateway, CDN, reverse proxy or load balancer could not get a valid response from the upstream service. Check whether the backend app is running, whether the upstream host and port are correct, whether a deployment just happened and whether the proxy timeout is too short. The frontend may only see 502, but the real error is usually in the gateway or upstream server logs.
Common mistakes when debugging status codes
Treating every 4xx code as the same problem
Not all client errors mean the same thing. A 400 points toward request structure. A 401 points toward authentication. A 403 points toward permission. A 404 points toward path or resource. A 422 points toward validation. A 429 points toward rate limit. If you treat all of them as a generic failure, you will waste time changing things that are unrelated to the actual category.
Ignoring redirects before the final error
Sometimes the visible error is only the final stop after one or more redirects. A request may start at HTTP, redirect to HTTPS, redirect to a login page, then return HTML instead of JSON. This is why the browser Network tab, cURL verbose output or API client history can be more useful than a single error message.
Testing with the wrong method
A route can exist but reject the method you used. For example, an endpoint may allow GET for reading records but require POST for creating a record. A 405 Method Not Allowed is a strong clue that the URL may be correct but the method is wrong. Always compare the method with the documentation before editing the URL.
Assuming 500 always means the user can do nothing
A 500 level code is server-side, but the client request can still trigger the server failure. A malformed payload, unexpected null value, oversized request, unsupported file, duplicate webhook or rare field combination can expose a backend bug. Save the request ID, timestamp and sanitized request body so the backend team can reproduce the issue.
Sharing unsafe debugging details
Status codes are safe to share, but full requests may contain API keys, bearer tokens, cookies, customer data or private URLs. Before posting in a forum, ticket or chat, remove secrets. Keep the useful debugging details: code, method, endpoint path, sanitized body, important headers, timestamp, request ID and what changed recently.
Troubleshooting checklist by context
| Context | What to inspect | Useful clue |
|---|---|---|
| Browser app | Network tab, CORS preflight, request payload, response body, final URL and blocked cookies. | If it works in Postman but fails in browser, CORS, origin rules or cookies may be involved. |
| Postman or API client | Environment variables, auth tab, generated headers, body mode, base URL and selected collection settings. | A wrong environment can make valid-looking requests fail with 401, 403 or 404. |
| WordPress | Permalinks, plugin conflicts, theme functions, REST API routes, hosting limits, cache and PHP error logs. | Site-wide 404 on posts often points to permalink rules, while 500 often needs PHP logs. |
| Webhook | Signature verification, event type, duplicate delivery, response time, retries, idempotency and raw body parsing. | Webhook providers may retry when your endpoint is slow or returns a non-2xx response. |
| SEO crawl | Final status, canonical target, redirect chain, robots rules, sitemap URL, internal links and page quality. | A 200 status does not guarantee indexing, and a 404 should be handled based on page value. |
| Server or hosting | Web server logs, app logs, proxy config, PHP or Node errors, memory limits, database connection and deployment history. | 502, 503 and 504 usually need gateway, hosting or upstream checks. |
When to use this tool vs related CodeZips tools
FAQ
Does this HTTP status code helper run on a server?
No. The helper runs in your browser with client-side JavaScript. The status code, URL and notes you enter are processed on the page and are not uploaded by this tool.
What does a 400 status code mean?
A 400 Bad Request usually means the server could not accept the request because of syntax, malformed JSON, invalid parameters, missing values, wrong content type or another request-shape problem.
What is the difference between 401 and 403?
A 401 usually means authentication is missing, invalid or expired. A 403 usually means the server understood the request but refuses access because of permissions, scopes, role, plan limit, origin rule or IP restriction.
Why do I get 404 if the page or endpoint exists?
A 404 can happen when the path, slug, route, API version, resource ID or environment is wrong. In WordPress, permalink rules and cache can also cause public pages to return 404 even when the post exists in the admin area.
What does 422 validation error mean?
A 422 response usually means the server understood the request body but rejected one or more values. Check required fields, field names, enum values, date formats, nested object structure, array format and field-level errors.
What should I do after a 429 error?
Stop rapid retries, check retry timing if available, reduce request frequency, remove accidental loops, batch requests carefully and inspect background jobs that may be sending duplicate requests.
Is a 500 error always the server owner’s fault?
A 500 level error means the server failed while processing the request, but the client request can still trigger the failure. Save the request ID, timestamp and sanitized request details so the backend team can reproduce it.
Why does my API return HTML instead of JSON?
An HTML response can mean you hit a website page, login page, CDN block page, firewall page, redirect or wrong route instead of the expected API endpoint. Check the final URL, redirects, content type and base URL.
Can this tool tell me exactly what my hosting server is doing?
No. It provides a practical explanation and checklist based on common HTTP patterns. Exact hosting problems may require server logs, app logs, provider status pages, resource metrics or hosting support.
What should I copy into a support ticket?
Include the status code, method, sanitized URL or path, context, response body if safe, response headers if relevant, timestamp, request ID, what changed recently and steps to reproduce. Do not include API keys, bearer tokens, cookies or private customer data.
Final practical note
Status codes are small, but they are powerful debugging clues when you read them in the right order. Start with the family, then the exact code, then the context, then the response body and headers. A 401 needs a different path than a 422. A 404 in WordPress needs different checks than a 404 in an API. A 502 needs a different mindset than a 400. Use this tool to slow down, collect the right facts and avoid changing random things before you understand what the server is actually telling you.
