Arunangshu Das

Posted on Jun 12

The One Line of Code That Crashes Most Node.js Apps

#webdev #node #discuss #explainlikeimfive

“It was just one line.”

That’s what every developer says before their Node.js app crashes in production.

Whether it’s a sleepy Sunday morning deployment or a high-traffic Black Friday backend surge, this one seemingly harmless line of code sneaks in quietly… and blows things up spectacularly.

The Culprit: `JSON.parse(req.body)`

Yes, that’s it.

This seemingly innocent line is the silent killer of countless Node.js apps, especially in Express-based servers and APIs.

Let’s break it down and explain why it causes so much trouble.

1. What Happens When You Call `JSON.parse(req.body)` Directly?

Most developers know that when working with an incoming request in Express or Node’s built-in http module, the req.body contains the data sent by the client.

But here’s the kicker:

`req.body` is not always a string.

If you're using a body parser like express.json(), then req.body is already an object. Parsing it again with JSON.parse() leads to a crash.

Here’s what a developer might accidentally do:

app.post('/data', (req, res) => {
  const data = JSON.parse(req.body); // ❌ CRASHES HERE
  // handle data
});

Result:

SyntaxError: Unexpected token o in JSON at position 1

Because it's trying to parse something that's already parsed. It's like trying to turn a cake back into eggs and flour.

2. Real-World Crash Scenario

Let’s walk through what this looks like in production:

The Setup:

You’re running an Express.js API. The middleware is set up like this:

app.use(express.json());

This automatically parses incoming Content-Type: application/json requests into JavaScript objects. So when the handler gets the request, req.body is already a usable object.

But a new developer on the team—or maybe your past self—adds:

const userInput = JSON.parse(req.body);

Boom.

Now every valid request results in a crash, because the code is trying to parse an already-parsed object.

The Impact:

App crashes immediately.
No error handling catches it.
High latency or downtime for all users.
You get paged at 3 a.m. by your monitoring tool.
Blame is thrown around.

3. Why Is This So Common?

Because it’s deceptively simple.

Junior developers copy-paste from tutorials or Stack Overflow.
Middleware order isn’t understood well.
The difference between raw request body and parsed body isn’t always obvious.
JSON parsing feels so universal that we instinctively reach for JSON.parse().

Also, consider this: if the middleware isn't set up (or fails), then the lack of JSON.parse() is the problem. So now you’re either:

Parsing too early (when it’s already parsed), or
Not parsing at all (when you need to).

It’s a fragile edge.

4. Spotting the Crash: How I Caught It

In one audit I did for a startup’s Node.js API, they complained about random crashes after deployments, even though nothing major changed.

The smoking gun?

// utils/input.js
module.exports.parseInput = (body) => {
  return JSON.parse(body);
};

This utility function was used everywhere in route handlers like:

const { parseInput } = require('./utils/input');
 
app.post('/form', (req, res) => {
  const formData = parseInput(req.body); 
});

The team had recently introduced express.json(), but never updated the utility. So now, all incoming POST routes were crashing.

We fixed it by detecting the type before parsing:

function safeParseBody(body) {
  if (typeof body === 'string') {
    try {
      return JSON.parse(body);
    } catch (err) {
      console.error('Invalid JSON:', err.message);
      return null;
    }
  }
  return body;
}

Lesson learned: Never assume the body is a string. Always check.

5. The Proper Way to Handle JSON in Node.js

Here’s a safe, modern approach using Express:

1. Use built-in middleware correctly

const express = require('express');
const app = express();
 
app.use(express.json()); // Automatically parses application/json

This makes req.body always a usable object (assuming the client sends valid JSON).

2. Handle edge cases

Sometimes, the client might send invalid JSON, or no JSON at all. Use error-handling middleware:

app.use((err, req, res, next) => {
  if (err instanceof SyntaxError && err.status === 400 && 'body' in err) {
    return res.status(400).json({ error: 'Invalid JSON payload' });
  }
  next();
});

3. Never manually parse if already parsed

Avoid this:

const data = JSON.parse(req.body);

Do this:

const data = req.body; //

If you're unsure about the type:

const data = typeof req.body === 'string' ? JSON.parse(req.body) : req.body;

6. Testing for It

Write automated tests that send both string and object payloads to your API and ensure your routes can handle both.

Example using Supertest:

const request = require('supertest');
 
it('handles valid JSON payload', async () => {
  await request(app)
    .post('/test')
    .send({ name: 'Test' })
    .expect(200);
});
 
it('handles invalid JSON payload gracefully', async () => {
  await request(app)
    .post('/test')
    .set('Content-Type', 'application/json')
    .send('{"broken": ') // invalid JSON
    .expect(400);
});

7. Other Variants of the Same Problem

This issue isn’t limited to req.body. You’ll see similar bugs when:

Using fs.readFile and then JSON.parse() without checking if the file is already parsed.
Reading a file with .json extension via require() and then parsing it again.
Parsing localStorage.getItem() values in browser apps multiple times.

8. Bonus: Security Implications

Improper JSON parsing opens up security holes too.

JSON Parsing Attacks:

Attackers can craft requests with large JSON payloads that exhaust the server memory if you’re blindly parsing every request manually with JSON.parse().

Or they can break your API by sending Content-Type: text/plain which skips your JSON middleware and hits your manual parser directly—causing a crash.

Mitigate this with:

app.use(express.json({ limit: '100kb' })); // prevent large payloads

9. Your JSON Safety Checklist

Before we wrap up, here’s a checklist to avoid this one-liner mistake in production:

→ Use express.json() middleware early in the stack.
→ Never parse req.body manually unless you have a reason.
→ Use content-type checks and validations.
→ Add error-handling middleware for SyntaxError.
→ Log suspicious or malformed payloads.
→ Set limits to prevent abuse.
→ Write automated tests for API input edge cases.
→ Don’t blindly copy-paste parsing code from tutorials.

Final Thoughts: Small Line, Big Impact

One line. That’s all it takes to break a high-performing Node.js backend.

And yet, this single line:

JSON.parse(req.body);

…has likely caused more damage than a dozen serverless misconfigurations combined.

Don’t underestimate it.

The best Node.js developers aren’t the ones who write the most clever code—they’re the ones who know when not to write code that doesn’t belong.

** TL;DR**

Don’t manually parse req.body if you're already using express.json().
Use defensive coding and proper middleware setup.
One line of bad code can lead to massive outages.
Review every use of JSON.parse() in your codebase today.

You may also like:

Read more blogs from Here

You can easily reach me with a quick call right from here.

Share your experiences in the comments, and let's discuss how to tackle them!

Follow me on LinkedIn

Top comments (1)

Some comments may only be visible to logged-in visitors. Sign in to view all comments.

The Culprit: JSON.parse(req.body)

1. What Happens When You Call JSON.parse(req.body) Directly?

req.body is not always a string.