Skip to main content

Command Palette

Search for a command to run...

A Simple HTTP Status Code Cheat, Maybe?

Published
5 min read
A Simple HTTP Status Code Cheat, Maybe?
A

I’m a Frontend Developer and Technical Writer passionate about creating user-friendly digital experiences and clear, developer-focused documentation. I work with Angular, Next.js, GetOutline, Docsify, Docusaurus, and Astro to build responsive web applications, and I write about code, design, and real-world lessons from building. Beyond code, I enjoy watching cool RomCom, exploring good food, documenting developer tools, auditing APIs, and crafting tutorials that make complex systems simple to understand.

I used to be puzzled by how senior developers instantly knew what to do based on the HTTP status codes they saw in the network tab. They would glance at the response and say things like, “Let me check the endpoint or payload,” or “It’s something on the backend or the server,” or even just “Hold on, let’s see if something else pops up.” Sure, I knew that the famous 200 status meant all was good, but beyond that, I had to constantly look up codes whenever they came up.

Then, I came across a hack in Dr. Angela Yu’s Udemy course, where she referenced a keynote from Sander Hoogendoorn. He shared a simple way to remember the categories of HTTP status codes:

  • 100’s → Hold on

  • 200’s → Here you go!

  • 300’s → Go away.

  • 400’s → You screwed up (client-side)

  • 500’s → I screwed up (server-side)

This tip really helped me reduce the time I spent searching for what each status code meant. Now, like senior devs 🤭🙈, I can quickly identify where the issue might be coming from just by looking at the first digit of the status code. While I still refer to the documentation for details, this cheat sheet gives me a great starting point. I’m sharing this with you in the hopes that it helps you too!


What Are HTTP Codes?

HTTP status codes are three-digit messages from a server in response to a browser's request. They help communicate how the request was handled — whether successful, redirected, failed, or other properties about the result of the request. They are essential in web development, giving developers and browsers critical information about the state of the server and the requested resource.

Why Are They Helpful?

1. They provide insights for debugging and error handling. By recognizing the meaning behind the codes, developers can focus their debugging efforts, quickly detect the root of issues, and hence; speed up the development process.

2. These codes serve as communication bridges between the client and server-side; to handle actions such as browser behavior, redirects, caching, etc.

3. HTTP response codes play an important role in user experience and search engine optimization. For instance, search engines use these codes to discover and evaluate the health of a website. Then, the 404 - not found pages guide users on the line of action to take - whether they inputted the wrong URL or the page is no longer available.
4. Search engines are not the only ones who monitor the health of an application with status codes. DevOps team can also proactively use HTTP codes to monitor and spot issues with the server.

Common HTTP Status Codes and Their Meanings

While I have the summarized bit, I still need some of the short explanations below to guide me in my debugging process. Here’s a quick run-through of some common HTTP status codes to help diagnose issues faster:

  • 100 Continue The server has received the initial part of the request, and the client should proceed to send the request body.

  • 200 OK The request was successful, and the server returned the requested resource.

  • 201 Created The request has been fulfilled, and a new resource has been created.

  • 204 No Content The server successfully processed the request, but there is no content to send back.

  • 301 Moved Permanently The resource has been permanently moved to a new URL.

  • 302 Found The resource is temporarily located at a different URL.

  • 304 Not Modified The resource has not been modified since the last request, and the client can use the cached version.

  • 400 Bad Request The server could not understand the request due to invalid syntax.

  • 401 Unauthorized The client must authenticate itself to get the requested response.

  • 403 Forbidden The server understands the request, but the client does not have permission to access the resource.

  • 404 Not Found The server could not find the requested resource.

  • 410 Gone The resource is no longer available and has been permanently removed.

  • 500 Internal Server Error The server encountered an unexpected condition that prevented it from fulfilling the request.

  • 501 Not Implemented The server does not support the functionality required to fulfill the request.

  • 502 Bad Gateway The server, while trying to process the request, received an invalid response from another server it relied on to fulfill the request.

  • 503 Service Unavailable The server is not ready to handle the request, often due to being overloaded or down for maintenance.

  • 504 Gateway Timeout The server, while acting as a gateway, did not receive a timely response from the upstream server.

  • 505 HTTP Version Not Supported The server does not support the version of HTTP used in the request.


So now whenever I come across status codes, I have this shortcode in my head with the brief explanations above.

  • 100's → wait

  • 200's → good

  • 300's → go

  • 400's → my bad

  • 500's → your bad

Feel free to create your own version or stick to Sander Hoogendoorn’s! As I have highlighted earlier, this cheat is not a replacement for deep research, but it’s a practical starting point for quickly diagnosing HTTP status codes and speeding up your development process.

Further Reading