Best Website Optimization Tools for No-Code Builders
Speed up your site and improve performance with these essential optimization tools.
Complete HTTP status codes reference with cause and fix steps. Search 200, 301, 404, 500, 502, 503 and every 1xx-5xx code. Includes Nginx codes and deprecated tags.
Complete HTTP status codes reference with cause and fix steps. Search 200, 301, 404, 500, 502, 503 and every 1xx-5xx code. Includes Nginx codes and deprecated tags.
The server has received the request headers and the client should proceed to send the request body. Useful for large POST requests - client sends "Expect: 100-continue" first.
Client sent an Expect: 100-continue header before transmitting a large request body.
Server signals readiness - client proceeds to send the body. No action needed.
The server is switching to the protocol specified in the Upgrade header. Most commonly used to upgrade an HTTP/1.1 connection to a WebSocket.
Client requested a protocol upgrade via the Upgrade header (e.g., HTTP → WebSocket or HTTP/2).
Expected behaviour - proceed with the upgraded protocol connection.
The server has received the request and is processing it, but no response is available yet. Prevents the client from timing out assuming the request was lost. (WebDAV)
Server sending an interim response to prevent timeout during a long-running WebDAV operation.
Wait for the final response. This code is deprecated - avoid relying on it in new implementations.
Used with the Link header to let the browser start preloading resources while the server is still preparing the full response. Improves page speed.
Server is sending preload hints before the main response is ready.
No action needed - benefits page load performance automatically.
Standard response for successful HTTP requests. The actual response depends on the method: GET returns the resource, POST returns the result of the action.
Standard successful response to any HTTP request.
No action needed.
The request has been fulfilled and a new resource has been created. The URI of the new resource is returned in the Location header. Typically used after POST or PUT.
POST or PUT request successfully created a new resource.
No action needed - check the Location response header for the URL of the new resource.
The request has been accepted for processing, but the processing has not been completed. The request might or might not be eventually acted upon (asynchronous processing).
Request accepted for async processing - the server has not finished yet.
Poll the API for the result, use a webhook callback, or check the response body for a status URL.
The server is a transforming proxy that received a 200 OK from its origin but is returning a modified version of the response.
A proxy or CDN modified the origin server's response (e.g., stripped headers, cached version).
Use a direct connection if you need unmodified data from the origin server.
The server successfully processed the request and is not returning any content. Commonly used for DELETE requests or editor save operations.
The operation succeeded but there is no content to return (typical for DELETE, PUT update, etc.).
No action needed - expected response for operations that produce no output.
The server successfully processed the request and asks that the requester reset its document view. Useful after form submissions.
Server instructs the client to clear/reset the form or document view after a successful submission.
Reset active form fields or UI state - the server request is complete.
The server is delivering only part of the resource due to a Range header sent by the client. Used for resumable downloads and video streaming.
Client sent a Range header to request a specific byte range (streaming, resumable downloads).
No action needed - expected behaviour for range requests.
The message body is an XML document containing a number of separate response codes for multiple sub-requests. (WebDAV)
A WebDAV batch operation affected multiple resources and each has its own status.
Parse the XML response body and check each individual resource's status code.
Members of a DAV binding have already been enumerated in a preceding part of the multi-status response and are not included again. (WebDAV)
WebDAV multi-status response avoiding duplicate enumeration of already-reported bindings.
No action needed - prevents infinite loops in complex DAV collection bindings.
The server has fulfilled a GET request and the response is a representation of one or more instance-manipulations applied to the current instance.
Server applied delta encoding (HTTP Delta encoding, RFC 3229) to a requested resource.
Client applies the instance manipulation (e.g., delta patch) to reconstruct the full response.
Indicates multiple options for the resource from which the client may choose - for example, a list of different language versions of a page.
Multiple representations of the requested resource exist (different formats, languages).
Choose one of the returned options or send proper content negotiation headers (Accept, Accept-Language).
The requested resource has been permanently moved to a new URL. Future requests should use the new URL. Search engines update their links.
Resource permanently moved - URL change, site migration, or canonical redirect.
Update all bookmarks and links to the new URL. Use 308 instead if you need to preserve the HTTP method.
The requested resource is temporarily at a different URI. The client should continue using the original URI for future requests.
Temporary redirect - maintenance page, A/B testing, or login redirect.
Follow the redirect. Use 307 if you need the HTTP method to be preserved.
The response to the request can be found under another URL using GET. Used to redirect after a POST/PUT/DELETE to prevent duplicate form submissions.
POST/PUT/DELETE completed - server redirects to the result page using GET (Post/Redirect/Get pattern).
Follow the GET redirect - prevents duplicate form submissions if the user refreshes.
Resource has not been modified since the version specified in the request headers (If-Modified-Since or If-None-Match). Client should use its cached version.
Client sent a conditional request and the resource has not changed since the cached version.
Use the cached version - no download needed. Check cache-control headers if caching behaves unexpectedly.
Previously defined to indicate that a request must be accessed via a proxy. Deprecated due to security concerns around in-band proxy configuration.
This code was defined in HTTP/1.1 but quickly deprecated - should never appear in modern systems.
Avoid implementing or relying on this code. Configure proxy settings out-of-band.
The request should be repeated with another URI, but the HTTP method must not change. Unlike 302, the method is guaranteed to be preserved in the redirect.
Temporary redirect where the HTTP method (POST, PUT, etc.) must be preserved.
Follow the redirect with the same method. Use 302 only if changing to GET on redirect is acceptable.
The request and all future requests should be repeated using another URI. Like 301, but the HTTP method must not change.
Permanent URL change where the original HTTP method must be preserved (e.g., POST stays POST).
Update bookmarks and links to the new URL. Preferred over 301 when POST requests must be preserved.
The server cannot or will not process the request due to an apparent client error - malformed syntax, invalid framing, or deceptive request routing.
Invalid JSON/XML body, missing required fields, bad query parameters, or malformed headers.
Validate the request body format, ensure all required parameters are present, and check header values.
Authentication is required and has failed or has not been provided. The response includes a WWW-Authenticate header.
Missing, expired, or invalid authentication credentials (token, API key, session cookie).
Include valid credentials. Check Authorization header format, verify the token has not expired, and re-authenticate.
Reserved for future use. Some services use it for quota enforcement or when payment is required to access a resource.
API quota exceeded, subscription expired, or payment required for the requested resource.
Check your subscription status, API quota limit, or payment details with the service provider.
The client's identity is known but it does not have access rights to the content. Unlike 401, re-authentication will not help.
Authenticated user lacks permission for this resource - wrong role, missing scope, or IP block.
Check user roles and permissions. Ensure the account or API key has the required access for this resource.
The server cannot find the requested resource. Could mean the URL is wrong, the resource was deleted, or it is temporarily unavailable.
URL typo, resource deleted, wrong API version, or intentional 404 used to hide a forbidden resource.
Verify the URL path. Check if the resource was moved (look for a Location header) or permanently deleted.
The request method is known by the server but is not supported by the target resource (e.g., sending DELETE to a read-only endpoint).
Using the wrong HTTP method for the endpoint (e.g., POST to a GET-only route).
Check the Allow response header for supported methods. Review API documentation for the correct method.
The server cannot produce a response matching the Accept headers in the request and is unwilling to supply a default representation.
Accept header specifies a content type the server cannot produce (e.g., requesting XML from a JSON-only API).
Remove or broaden the Accept header. Check what response formats the API supports.
The client must first authenticate with the proxy server before the request can be served.
Corporate or ISP proxy requires authentication credentials before forwarding the request.
Provide proxy credentials. Check the Proxy-Authorization and Proxy-Authenticate response headers.
The server timed out waiting for the request. The client did not produce a request within the time the server was prepared to wait.
Slow network, large payload, or client-side delay caused the connection to idle past the server timeout.
Check network speed, increase client timeout settings, optimise payload size, and retry.
The request could not be completed due to a conflict with the current state of the target resource.
Duplicate resource creation, edit conflict (two users editing simultaneously), or version mismatch.
Fetch the latest version and resolve the conflict using ETags or timestamps, then retry.
The resource was previously available but has been deliberately and permanently removed with no forwarding address.
Resource intentionally and permanently deleted - unlike 404, this signals it will never return.
Remove all cached links. Unlike 404 this is permanent - do not retry.
The server refuses to accept the request without a defined Content-Length header.
POST or PUT request is missing the Content-Length header that the server requires.
Add a Content-Length header set to the exact byte length of the request body.
The server does not meet one of the conditional preconditions in the request headers (e.g., If-Match, If-Unmodified-Since).
Resource was modified by another client between your GET and your conditional PUT or DELETE.
Fetch the latest ETag with a new GET request, update your conditional headers, then retry.
The request entity is larger than the server is willing to process. The server may close the connection or return a Retry-After header.
File upload or request body exceeds the server's configured maximum size limit.
Compress the payload, chunk the upload into smaller parts, or increase the server body size limit (e.g., Nginx client_max_body_size).
The URI provided by the client was longer than the server is willing to interpret.
Too many or too long query parameters, redirect loop converting POST→GET appending data, or overly long path.
Move query parameters into a POST request body. Shorten the URL. Check for redirect loops.
The server does not support the media format of the requested data (e.g., client uploads SVG but server requires GIF).
Wrong or missing Content-Type header - such as sending JSON without setting application/json.
Set the correct Content-Type header. Check API documentation for accepted media types.
The Range header in the request cannot be satisfied - the range extends beyond the end of the resource.
Range header requests bytes past the end of the file, or the resource was modified after a prior range request.
Validate range bounds against file size. Re-fetch Content-Range metadata with a HEAD request.
The server cannot meet the requirements of the Expect request-header field. Typically happens when the server cannot comply with "100-continue".
Server does not support the Expect header value sent by the client.
Remove the Expect header from the request, or ensure the server supports the declared expectation.
Any attempt to brew coffee with a teapot should result in the error code 418. Defined as an April Fools' joke in RFC 2324. Not expected to be implemented by actual HTTP servers.
You attempted to brew coffee with a teapot.
Use an appropriate coffee-brewing device. This is a real RFC (2324) but not a production error code.
Request directed at a server not able to produce a response - e.g., connection reuse with a wrong host or TLS SNI mismatch.
HTTP/2 connection reuse sent a request to a server that does not host that domain, or a TLS SNI mismatch.
Retry using a new, dedicated connection. Check TLS SNI and virtual host configuration.
The request was well-formed but could not be followed due to semantic errors - such as validation errors in a JSON or XML payload.
Request body is syntactically valid but semantically wrong - missing required fields, wrong data types, or constraint violations.
Check the response body for specific field-level validation errors. Validate input data before sending.
The resource being accessed is locked. (WebDAV)
Another WebDAV client holds a write lock on the resource.
Wait for the lock to expire or send an UNLOCK request with the correct lock token.
The request failed because it depended on another request and that request failed. (WebDAV)
A dependent sub-request in a WebDAV batch operation failed, causing this request to fail too.
Identify and fix the failed dependency first, then retry the entire operation.
The server is unwilling to risk processing a request that might be replayed. Used to reject TLS early data (0-RTT) that could be a replay attack.
Request was sent as TLS 0-RTT early data which the server will not process due to replay attack risk.
Retry the request without TLS early data. Disable 0-RTT in TLS client configuration.
The server refuses to perform the request using the current protocol but will do so after the client upgrades, indicated in the Upgrade header.
Server requires a protocol upgrade (e.g., HTTP/1.1 → HTTP/2 or WebSocket) before serving the request.
Upgrade the connection to the protocol specified in the Upgrade response header.
The origin server requires the request to be conditional. Intended to prevent the "lost update" problem.
Server enforces optimistic locking - requests must include conditional headers like If-Match.
Include an If-Match header with the current ETag to prevent concurrent update conflicts.
The user has sent too many requests in a given amount of time - rate limiting. Server may include a Retry-After header.
Rate limit exceeded - too many API calls in a short time window.
Check the Retry-After response header. Implement exponential backoff before retrying.
The server is unwilling to process the request because its header fields are too large.
Oversized cookies, too many headers, or very long Authorization or Cookie header values.
Clear old cookies, reduce cookie size, shorten header values, or use shorter tokens.
Nginx-specific - the server closed the connection without sending a response. Often used to silently reject malicious or invalid requests.
Nginx is configured to silently drop requests matching a certain pattern (bots, blocked IPs, bad host headers).
Check Nginx access and error logs. Review server block configuration for return 444 directives.
The server operator received a legal demand to deny access - e.g., government censorship, DMCA request, or a court order. Named as a reference to Fahrenheit 451.
Legal takedown notice, DMCA request, government censorship, or court order.
No technical fix available - this is a legal or policy restriction on the resource.
Nginx-specific - the client disconnected before the server finished responding. Logged when clients abort long-running requests.
Client timeout, user navigated away, or a slow backend caused the client to give up waiting.
Check client-side timeout settings. Optimise slow backend queries that are causing long response times.
A generic error given when an unexpected condition was encountered and no more specific message is suitable. The most common server-side error.
Unhandled exception, application crash, database error, or misconfiguration in server code.
Check server error logs. Review recent deployments. Add proper exception handling to catch unhandled errors.
The server either does not recognise the request method or lacks the ability to fulfil the request. Unlike 405, this implies future availability.
Client used an HTTP method (e.g., PATCH) that the server does not support at all.
Use a supported HTTP method. Check API documentation for available endpoints and methods.
The server was acting as a gateway or proxy and received an invalid response from the upstream server.
Upstream server crashed or restarted, network issues between proxy and backend, or upstream returned invalid HTTP.
Check upstream server health and logs. Review Nginx/proxy timeout settings. Verify network connectivity between proxy and backend.
The server cannot handle the request because it is overloaded or down for maintenance. Generally a temporary state.
Server overloaded (CPU/RAM/connections maxed), maintenance mode, or application pool crashed.
Check server resources. Scale horizontally. Implement request queuing. Check the Retry-After header.
The server was acting as a gateway or proxy and did not receive a timely response from an upstream server.
Slow backend query, upstream server hanging, or proxy timeout configured too short.
Increase proxy timeout limits. Optimise slow database queries. Check upstream server performance and health.
The server does not support the HTTP version used in the request.
Client used HTTP/2 or HTTP/3 with a server that only supports HTTP/1.1, or vice versa.
Fall back to HTTP/1.1. Check server configuration for supported protocol versions.
Transparent content negotiation for the request results in a circular reference - an internal server configuration error.
Server misconfiguration - the selected content variant is itself configured for content negotiation.
Fix the server-side configuration. The selected variant should serve a fixed representation, not negotiate.
The server is unable to store the representation needed to complete the request. (WebDAV)
Server disk is full or the storage quota for the WebDAV user or collection has been exceeded.
Free up server disk space, increase the storage quota, or move data to different storage.
The server detected an infinite loop while processing a request. (WebDAV)
WebDAV collection structure contains a circular reference - a member of a collection binds back to itself.
Inspect the WebDAV collection structure and remove all circular bindings.
Further extensions to the request are required for the server to fulfil it. The server sends back a list of required extensions.
The request declares an HTTP extension (RFC 2774) that the server requires but the client did not include.
Include the required HTTP extension headers as specified in the server's response.
The client needs to authenticate to gain network access. Intended for captive portals like hotel or café Wi-Fi login pages.
Device is behind a captive portal (public Wi-Fi, hotel network) requiring browser-based network login.
Open a browser - you will be redirected to the network login page. Complete authentication to gain access.
Informal code used by some proxies to signal a network connection timeout when trying to reach the origin server.
Proxy could not establish a network connection to the upstream server within the timeout period.
Check DNS resolution, firewall rules, and network connectivity between the proxy and the origin server.
No status codes match your search.
Our HTTP Status Codes Reference covers all 60+ HTTP status codes - 1xx Informational, 2xx Success, 3xx Redirection, 4xx Client Errors, and 5xx Server Errors - plus unofficial Nginx-specific codes. Whether you encounter a 502 Bad Gateway, a 429 Too Many Requests, a 307 Temporary Redirect, or an unexpected 499, this reference explains exactly what it means and how to fix it.
Every code card includes the most likely cause and actionable fix steps. When your API returns a 422 Unprocessable Entity or a load balancer sends a 503, you get a concrete starting point for debugging instead of a vague definition. Fix instructions are specific to the code, not just generic error handling advice.
Codes are tagged with context badges that tell you their status at a glance: Deprecated marks codes you should avoid in new implementations, Experimental flags newer additions not yet universally supported, WebDAV identifies extension codes used in file-sharing protocols, and Unofficial covers widely-used codes like Nginx's 444 that fall outside the official HTTP spec.
The search box filters by code number, name, or any keyword in the description as you type. Each standard code includes a one-click link to its official RFC specification. Works entirely in your browser with no server required.
Everything you need in one amazing tool
All 60+ HTTP status codes (1xx-5xx) including unofficial Nginx-specific codes - the most comprehensive list available
Search by code number, name or description - instantly find the meaning of any status code
Codes tagged as Deprecated, Experimental, WebDAV, Fun, or Unofficial so you instantly know their context
Every card shows the most likely cause of that status code - no more guessing why an error occurs
Actionable fix instructions for every code - exactly what to do when you encounter that status
One-click link to the official RFC specification for every standard status code
Get started in 4 easy steps
Scroll through complete list organized by category (1xx-5xx)
Find specific codes like "404" or search "redirect"
Click any card to see the most common cause and actionable fix steps for that status code
Click the spec link on any standard code to open its official RFC documentation in one tap
Stand out from the competition
All 60+ codes including unofficial Nginx codes (444, 499) and deprecated ones - nothing left out
Visual Deprecated / Experimental / WebDAV / Unofficial badges so you always know the context
Every code shows the most common cause and actionable fix steps - not just a definition
Each standard code links to the official specification for deeper reading
Search by number, name, or keyword across all codes instantly
Fully static - no server requests, works offline after the first load
See how others are using this tool
Debug API errors by looking up HTTP status codes returned by endpoints
Understand server responses when troubleshooting website issues and downtime
Learn REST API conventions to implement proper status codes in your backend
Fix SEO issues caused by incorrect redirect codes (301 vs 302) or error pages
Interpret nginx/Apache error logs showing status codes for failed requests
Study for web development interviews where HTTP knowledge is commonly tested
Everything you need to know about HTTP Status Codes Reference
An HTTP status code is a 3-digit number a server sends back to tell the client whether a request succeeded or failed. Every HTTP response includes one. The first digit defines the category: 1xx (Informational) - provisional responses during processing (100 Continue, 101 Switching Protocols), rarely seen by users. 2xx (Success) - request succeeded (200 OK, 201 Created, 204 No Content). 3xx (Redirection) - further action required (301 Moved Permanently, 302 Found, 304 Not Modified). 4xx (Client Error) - client made an invalid request (400 Bad Request, 401 Unauthorized, 403 Forbidden, 404 Not Found) - problem is with the request. 5xx (Server Error) - server failed to process a valid request (500 Internal Server Error, 502 Bad Gateway, 503 Service Unavailable) - problem is with the server. Quick rule: 4xx means client's fault, 5xx means server's fault.
301 Moved Permanently: resource permanently moved to new URL, browsers/search engines should update bookmarks and links, SEO link juice transfers to new URL, aggressive caching (browsers may cache redirect forever), use for permanent URL changes. 302 Found (temporary redirect): resource temporarily at different URL, original URL still valid, search engines keep indexing original URL (no SEO transfer), less aggressive caching, use for maintenance redirects or A/B testing. Wrong choice consequences: 302 for permanent moves hurts SEO (split rankings), 301 for temporary moves makes temporary URL permanent in caches. Modern: 307 (Temporary) and 308 (Permanent) are stricter versions that preserve HTTP method. Always use 301 for permanent URL migrations.
401 Unauthorized: user not authenticated (not logged in), request lacks valid credentials, response includes WWW-Authenticate header prompting login, use when authentication required but missing. 403 Forbidden: user authenticated but lacks permission to access resource, credentials provided but insufficient privileges, use when logged-in user tries accessing forbidden resource (admin panel for regular users). 404 Not Found: resource does not exist at URL, URL is invalid or resource deleted, use when URL never existed or no longer exists. Confusion: 401 should be "Unauthenticated", 403 is true "Unauthorized" but names are historical. Security: return 404 for forbidden resources to hide their existence (unauthorized users should not know resource exists).
200 OK: general success for GET, PUT, PATCH (request succeeded, response body contains resource). Use for most successful operations that return data. 201 Created: resource successfully created (POST request), response includes Location header with new resource URL, response body typically contains created resource representation. Use specifically for creation operations. 204 No Content: successful request but no content to return (DELETE request, PUT update with no response needed), saves bandwidth by not sending body. Use when operation succeeds but client does not need response data. REST conventions: POST creating resource = 201, DELETE removing resource = 204, GET retrieving resource = 200, PUT updating resource = 200 or 204. Proper codes help API clients understand operation results without parsing response body.
502 Bad Gateway: gateway/proxy server (nginx, load balancer) received invalid response from upstream server (backend). Causes: upstream server crashed/restarted, network connectivity issue between proxy and backend, timeout waiting for upstream, upstream returned invalid HTTP. Fix: check upstream server logs, verify backend is running, increase proxy timeout settings, verify network connectivity. 503 Service Unavailable: server temporarily unable to handle request (overloaded, maintenance). Causes: server under heavy load/DDoS, application crashed, max connections reached, intentional maintenance mode. Fix: check server resources (CPU, memory, connections), scale up server capacity, implement rate limiting, check for traffic spikes. User response: both are temporary - retry after delay. APIs should include Retry-After header indicating when to retry.
A 500 Internal Server Error means the server hit an unexpected condition and could not complete the request - it is always the server's fault, never yours as a visitor. Common causes: unhandled exception in server code, database connection failure, misconfigured web server (nginx or Apache), out of memory or disk space, file permission errors, or a syntax error in a server-side script. Fix steps for developers: 1) Check server error logs immediately - they contain the actual exception trace. 2) Reproduce the request in staging. 3) Verify database connectivity. 4) Check server resource usage (CPU, memory, disk). 5) Review recent deployments and roll back if needed. 6) Verify file and folder permissions. As an end user: the problem is on the site owner's side - try again after a few minutes or contact support.
Best practices: GET retrieval: 200 OK (found), 404 Not Found (missing). POST creation: 201 Created with Location header, 400 Bad Request (validation failed), 409 Conflict (duplicate). PUT update: 200 OK or 204 No Content, 404 Not Found (resource missing). DELETE: 204 No Content (deleted), 404 Not Found (already gone/never existed). Authentication: 401 (not logged in), 403 (insufficient permissions). Validation errors: 400 Bad Request with error details in body. Server errors: 500 Internal Server Error (catch-all). Rate limiting: 429 Too Many Requests. Be consistent: document your codes, return same codes for same situations, include error details in response body, use standard codes (avoid custom codes in 4xx/5xx ranges). Proper codes enable generic client error handling.
Use our free tools to perfect your content and design, then build your full website yourself. No code needed, no developers to hire, no waiting.