DEV Community: ToolBench

Understanding HTTP Status Codes Every Developer Should Know (With Real API Examples)

ToolBench — Mon, 13 Jul 2026 12:46:28 +0000

Understanding HTTP Status Codes Every Developer Should Know (With Real API Examples)

If you've ever integrated an API, you've almost certainly encountered responses like 200 OK, 404 Not Found, or 500 Internal Server Error.

At first, these numbers can seem confusing. But once you understand what each status code means, debugging becomes much easier.

In this article, we'll explore the most common HTTP status codes, when they're returned, and how to respond to them as a developer.

What Are HTTP Status Codes?

HTTP status codes are standardized responses sent by a server after it receives a request from a client (such as a web browser, mobile app, or frontend application).

Every response contains two important pieces of information:

The status code
The response body (if any)

Example:

HTTP/1.1 200 OK
Content-Type: application/json

{
  "message": "User retrieved successfully"
}

The status code immediately tells you whether the request succeeded or failed.

The Five Categories of Status Codes

HTTP status codes are grouped into five categories.

Range	Meaning
1xx	Informational
2xx	Success
3xx	Redirection
4xx	Client Errors
5xx	Server Errors

Let's look at the ones you'll encounter most often.

200 OK

This is the response every developer wants to see.

It means the request was successful and the server returned the expected data.

Example:

GET /api/users/15

Response

200 OK

Response body

{
  "id": 15,
  "name": "John",
  "email": "john@example.com"
}

Use this when:

Fetching users
Loading products
Retrieving reports
Reading configuration data

201 Created

Returned after successfully creating a new resource.

Example:

POST /api/users

Response

201 Created

{
    "id": 101,
    "name": "Alice"
}

Typical use cases:

User registration
Creating blog posts
Adding products
Creating orders

204 No Content

Sometimes an operation succeeds but doesn't need to return any data.

Example:

DELETE /api/users/15

Response

204 No Content

This is commonly used after successful delete operations.

400 Bad Request

The server couldn't process the request because it was invalid.

Common reasons:

Missing required fields
Invalid JSON
Incorrect data types
Validation failures

Example:

{
    "email":"not-an-email"
}

Possible response

{
    "error":"Invalid email address"
}

Always validate user input before sending requests.

401 Unauthorized

Authentication is required.

Typical causes:

Missing JWT token
Expired access token
Invalid credentials

Example:

Authorization header missing

Response

401 Unauthorized

403 Forbidden

The user is authenticated but doesn't have permission.

Example:

A normal user tries to access an admin endpoint.

403 Forbidden

Think of it like this:

401 = "Who are you?"
403 = "I know who you are, but you're not allowed."

404 Not Found

Probably the most recognized status code.

It means the requested resource doesn't exist.

Example

GET /api/products/99999

Response

404 Not Found

Possible reasons:

Wrong URL
Deleted resource
Incorrect API version
Typo in endpoint

409 Conflict

Returned when a request conflicts with existing data.

Example:

Creating a user with an email address that's already registered.

{
    "email":"john@example.com"
}

Response

409 Conflict

422 Unprocessable Entity

The request is syntactically correct, but the provided data doesn't satisfy business rules.

Example:

{
    "age": -5
}

Response

{
    "error":"Age must be greater than zero."
}

Many modern REST APIs use this status code for validation errors.

500 Internal Server Error

This indicates something went wrong on the server.

Examples include:

Null reference exceptions
Database connection failures
Unexpected exceptions
Configuration issues

Example response

500 Internal Server Error

If you're building APIs, avoid exposing stack traces to clients. Instead, log the error internally and return a meaningful message.

503 Service Unavailable

The server is temporarily unavailable.

Possible reasons:

Scheduled maintenance
High traffic
Database outage
Dependency failure

Unlike a 500 error, a 503 often indicates the service may recover shortly.

Quick Reference

Status	Meaning
200	Success
201	Resource created
204	Success, no response body
400	Bad request
401	Authentication required
403	Permission denied
404	Resource not found
409	Conflict
422	Validation/business rule failure
500	Internal server error
503	Service temporarily unavailable

Best Practices

Use the correct status code instead of always returning 200.
Return clear, consistent error messages.
Validate input before processing requests.
Log server-side exceptions for troubleshooting.
Avoid exposing sensitive implementation details in error responses.
Document expected status codes in your API documentation.

Final Thoughts

Understanding HTTP status codes is one of the simplest ways to become more effective at debugging APIs and building reliable applications. Choosing the right response code also makes your APIs easier for other developers to integrate with and troubleshoot.

Which HTTP status code do you encounter most often in your day-to-day development? Share your experience in the comments—I’d love to hear your stories and debugging tips.

Explore More Developer Tools

If you regularly work with APIs, JSON, encoding, formatting, or debugging, check out ToolBenchApp: https://toolbenchapp.com/.

It's a growing collection of free browser-based developer tools designed to simplify everyday development tasks—whether you're formatting JSON, validating data, decoding JWTs, comparing text, or converting common formats. If you have ideas for a tool that would make your workflow easier, I'd love to hear your suggestions.

JSON Formatter vs JSON Validator: What's the Difference? (With Practical Examples)

ToolBench — Tue, 07 Jul 2026 12:09:07 +0000

If you've worked with APIs, configuration files, or frontend applications, you've almost certainly dealt with JSON.

Two tools that developers use every day are JSON Formatters and JSON Validators.

Many beginners assume they're the same thing, but they solve different problems.

Let's understand the difference with examples.

What is JSON?

JSON (JavaScript Object Notation) is a lightweight format used to exchange data between applications.

Example:

{"name":"Alice","age":28,"city":"London"}

While this works perfectly, it's difficult to read.

What is a JSON Formatter?

A JSON Formatter takes valid JSON and makes it human-readable by adding proper indentation and line breaks.

Input

{"name":"Alice","age":28,"skills":["JavaScript","React","Node.js"]}

Output

{
  "name": "Alice",
  "age": 28,
  "skills": [
    "JavaScript",
    "React",
    "Node.js"
  ]
}

Notice that nothing about the data changed.

Only the presentation improved.

Why use a formatter?

Easier debugging
Better code reviews
Improved readability
Faster navigation through nested objects
Cleaner API responses

What is a JSON Validator?

A JSON Validator checks whether your JSON follows the JSON specification.

If your JSON contains syntax errors, the validator tells you where the problem is.

Example of invalid JSON:

{
  "name":"Alice",
  "age":28,
}

The trailing comma after 28 makes this invalid.

A validator would return an error similar to:

Unexpected token } at line 3

Another example:

{
name:"Alice"
}

Keys must be enclosed in double quotes.

Correct version:

{
  "name": "Alice"
}

Formatter vs Validator

Feature	JSON Formatter	JSON Validator
Improves readability	✅	❌
Detects syntax errors	❌	✅
Changes formatting only	✅	❌
Checks JSON correctness	❌	✅
Useful before debugging	✅	✅

When should you use each?

Use a Formatter when:

API responses are difficult to read.
You're inspecting nested objects.
You want consistent formatting.

Use a Validator when:

An API rejects your request.
A configuration file fails to load.
Your parser throws a JSON error.
You want to verify copied JSON before using it.

Can one tool do both?

Yes.

Many modern developer tools first validate the JSON and then automatically format it if it's valid.

This saves time because you don't need separate tools for validation and beautification.

Final Thoughts

Although they sound similar, a JSON Formatter and a JSON Validator solve different problems.

A Formatter improves readability.
A Validator ensures correctness.

Using both together helps catch errors quickly and makes working with APIs much easier, especially when dealing with large or deeply nested JSON documents.

Which one do you use more often in your daily development workflow?

I built this while working on a collection of free developer utilities. If you'd like to try the formatter or explore the rest of the tools, you can find them at ToolBench: https://toolbenchapp.com/.

🚀 I Built a Free JSON Formatter — Here's What I Learned While Processing Large JSON Files in the Browser

ToolBench — Mon, 06 Jul 2026 11:57:06 +0000

👋 Introduction

If you've ever worked with APIs, you've probably encountered one of these situations:

A massive JSON response that's impossible to read.
An "Unexpected token" error with no clue where it occurred.
A minified JSON payload compressed into a single line.
A need to quickly validate whether your JSON is actually valid.

I ran into these problems almost every day while developing web applications.

Instead of repeatedly switching between different websites, I decided to build my own JSON Formatter as part of my developer tools platform.

Along the way, I learned a lot about browser performance, JSON parsing, and creating a better developer experience.

In this article, I'll share those lessons.

🤔 Why Do Developers Need a JSON Formatter?

Imagine receiving this API response:

{"user":{"id":101,"name":"John","address":{"city":"London","country":"UK"},"orders":[{"id":1,"amount":200},{"id":2,"amount":350}]}}

It's technically correct...

But can you quickly find the second order amount?

Probably not.

Now compare it with:

{
"user": {
"id": 101,
"name": "John",
"address": {
"city": "London",
"country": "UK"
},
"orders": [
{
"id": 1,
"amount": 200
},
{
"id": 2,
"amount": 350
}
]
}
}

💡 How JSON Formatting Works

Behind the scenes, formatting JSON is surprisingly simple.

const formatted = JSON.stringify(
JSON.parse(json),
null,
2
);

The process is:

Parse the JSON
Validate it
Convert it back with indentation

If the JSON is invalid, the parser throws an error.

🚨 Common JSON Mistakes

These are the issues I see most often.

❌ Missing comma

{
"name":"John"
"age":30
}

❌ Single quotes

{
'name':'John'
}

❌ Unmatched braces

{
"name":"John"

⚡ Performance Challenges

Formatting a small JSON file is easy.

Formatting a 20MB JSON file is a different story.

Some challenges include:

Browser freezing
High memory usage
Slow rendering
Delayed syntax highlighting

While building my formatter, I realized that handling large files efficiently requires careful optimization rather than simply calling JSON.stringify().

🛠 Features I Wanted

Instead of creating another basic formatter, I wanted something developers could actually use every day.

My checklist included:

JSON Formatting
JSON Validation
Minification
Pretty Print
Copy to Clipboard
Download JSON
Dark Mode
Mobile Friendly
Fast Performance

📈 Lessons I Learned

Building developer tools taught me that simplicity matters more than flashy design.

Developers want tools that are:

Fast
Reliable
Privacy-friendly
Easy to use
Free for common tasks

If a tool solves a problem in seconds, people come back.

💬 What Developer Tool Should I Build Next?

I'm currently expanding my developer tools platform and would love suggestions.

Ideas I'm considering:

JSON Compare
JSON to C# Class
JWT Decoder
SQL Formatter
YAML Formatter
Base64 Encoder
Image Compressor

Which one would you use the most?

Let me know in the comments.

🙌 Thanks for Reading

Thanks for taking the time to read this article.

If you're building developer tools or have ideas for features that save developers time, I'd love to hear about them.

Happy coding! 🚀

Helpful Resource:- https://toolbenchapp.com/tools/json-formatter