DEV Community: Tahmid

Why Your JSON Keeps Breaking (And How to Fix It Fast)

Tahmid — Sat, 18 Apr 2026 21:48:08 +0000

You paste a JSON config into your app and hit SyntaxError: Unexpected token. You scan 60 lines of curly braces, counting quotes by eye. Five minutes later you spot it — a trailing comma on line 47. Sound familiar?

JSON is ruthlessly strict. No trailing commas. No comments. No single quotes. No unquoted keys. Even one character out of place produces a completely opaque error message that points you to the wrong line half the time. This post covers the four JSON mistakes that cause 90% of parse failures, how to spot them instantly, and how to stop wasting time on them.

The Four Most Common JSON Errors

1. Trailing Commas

This is the most frequent offender, especially if your JSON was hand-written or copied from a JavaScript object literal.

Broken:

{
  "name": "Alice",
  "role": "admin",
  "active": true,
}

Fixed:

{
  "name": "Alice",
  "role": "admin",
  "active": true
}

The trailing comma after true is valid JavaScript but illegal JSON. Most parsers point you to the closing brace, not the offending comma, which sends you hunting in the wrong direction.

2. Single Quotes Instead of Double Quotes

Developers who spend most of their time in JavaScript or Python often reach for single quotes out of habit.

Broken:

{
  'username': 'bob',
  'permissions': ['read', 'write']
}

Fixed:

{
  "username": "bob",
  "permissions": ["read", "write"]
}

The JSON specification (RFC 8259) is explicit: strings must use double quotes. Single quotes are not valid, period.

3. Comments Embedded in JSON

If you copied a config from documentation or a README, it may include comments added for human clarity. JSON does not support comments.

Broken:

{
  // database settings
  "host": "localhost",
  "port": 5432,  /* default postgres port */
  "database": "myapp"
}

Fixed:

{
  "host": "localhost",
  "port": 5432,
  "database": "myapp"
}

Strip every // line comment and every /* */ block comment before parsing. If you need to annotate your configs, consider YAML or TOML — or adopt a _comment key as a convention.

4. JavaScript-Only Values

undefined, NaN, and Infinity are valid JavaScript but completely foreign to JSON. Only null, true, false, numbers, strings, arrays, and objects are allowed.

Broken:

{
  "count": NaN,
  "result": undefined,
  "ratio": Infinity
}

Fixed:

{
  "count": 0,
  "result": null,
  "ratio": null
}

These typically appear when serializing JavaScript objects that contain these special values — a common trap when using JSON.stringify() without a replacer function.

Stop Hunting for Errors by Eye

Reading JSON manually for syntax errors is a poor use of your attention. Paste your broken JSON into the JSON Formatter & Validator at jsonindenter.com and it will immediately highlight exactly which line is wrong and why. It also re-indents the output so that nested structures become readable at a glance — a lifesaver when someone hands you a 2KB single-line blob.

The validator catches all four of the errors described above and gives you a plain-English error message rather than the cryptic column-number output your runtime throws.

Comparing Two JSON Responses

Another common scenario: you have two versions of a JSON response — one from staging, one from production — and something is different but you can't tell what. Diffing them by eye across two editor tabs is tedious and error-prone.

The JSON Diff tool does a structural comparison of two JSON documents and highlights exactly which keys were added, removed, or changed in value. Because it understands JSON structure, it doesn't get confused by whitespace changes or key reordering — it shows you only what actually changed semantically.

Minifying for Production

Once your JSON is clean and validated, you may want to strip all whitespace before embedding it in a build artifact or sending it over the wire. The JSON Minifier removes all unnecessary whitespace in one click. For a 500-line formatted config file, the minified output is typically 3–5× smaller by byte count — a meaningful difference in payload-sensitive contexts like mobile APIs or edge functions.

A Practical Debugging Workflow

When JSON breaks in a project, this three-step process gets me to a fix in under two minutes:

Paste into the formatter — it shows the exact error location and corrects indentation so the structure is visible
Fix the flagged issue and validate again until the document is clean
If the JSON parses successfully but behavior is still wrong, use the diff tool to compare against the last known-good version line by line

This replaces what used to be ten minutes of manual scanning and guessing.

The Bigger Picture

Most JSON headaches come from the same handful of mistakes, and almost all of them come from editing JSON by hand or copying it from contexts that allow looser syntax — JavaScript objects, Python dicts, config files with comments. The fix isn't memorizing the spec; it's building a habit of running JSON through a validator before it ever reaches your parser.

What's your most painful "I spent an hour on a trailing comma" story? Drop it in the comments — I know I'm not the only one who's been there.

Free tools used in this post:

JSON Formatter & Validator — paste broken JSON and get instant error highlighting with clean re-indentation
JSON Diff — structural comparison of two JSON documents, shows exactly what changed semantically
JSON Minifier — strips all whitespace from JSON for smaller payloads
All tools — client-side, no sign-up, nothing leaves your browser

How to Compare Two JSON Objects and Spot the Differences Instantly

Tahmid — Sat, 18 Apr 2026 21:47:55 +0000

You're two hours into debugging a production issue. Your API contract says the response should look like this:

{
  "user": {
    "id": 42,
    "name": "Alice",
    "role": "admin",
    "active": true
  },
  "permissions": ["read", "write", "delete"]
}

But something downstream is breaking. You log the actual response and squint at it. It looks the same. Roughly. But your authorization middleware just denied an admin user.

That's when you notice: "role" is missing. Or it became "roles". Or "active" is now the string "true" instead of a boolean. Bugs like this are trivially small and brutally hard to spot in a wall of JSON text — especially when the payload is minified or poorly indented.

Here's a practical workflow for comparing two JSON objects and catching differences before they catch you.

Step 1: Format both objects identically

Comparing minified JSON visually is a waste of time. If your two blobs have different indentation, trailing whitespace, or inconsistent key ordering, even a side-by-side diff tool will light up with false positives.

Before anything else, run both objects through a formatter. Paste each one into JSON Indenter and make sure you're comparing apples to apples: same indentation style, same structure, same readability.

Before (minified):

{"user":{"id":42,"name":"Alice","role":"admin","active":true},"permissions":["read","write","delete"]}

After (formatted):

{
  "user": {
    "id": 42,
    "name": "Alice",
    "role": "admin",
    "active": true
  },
  "permissions": ["read", "write", "delete"]
}

Now you can actually read it. This single step eliminates a whole class of "differences" that are really just formatting noise.

Step 2: Validate before you compare

If either object has a syntax error, your diff will give you nonsense. A stray trailing comma, an unquoted key, or a missing bracket will corrupt the comparison before it starts.

Run both objects through the JSON Validator before proceeding. It surfaces syntax errors with exact line numbers, so you fix the structure first and compare content second.

This matters more than you'd think. Many JSON objects in the wild come from sources that produce technically invalid JSON — config files with comments, legacy APIs with trailing commas, log entries with prepended timestamps. Validate early.

Step 3: Compare programmatically when you need precision

For automated tests or CI pipelines, visual comparison doesn't scale. Here's where programmatic diffing becomes essential.

The naive approach — and why it fails:

const a = { user: { id: 42, name: "Alice" } };
const b = { user: { name: "Alice", id: 42 } };

console.log(JSON.stringify(a) === JSON.stringify(b));
// false — key order matters for string comparison, not for JSON semantics

JSON.stringify is order-sensitive. Two objects that are semantically identical can produce different strings if their keys were inserted in a different order.

A better approach — recursive diff with specific output:

function jsonDiff(a, b, path = "") {
  const diffs = [];
  const allKeys = new Set([...Object.keys(a), ...Object.keys(b)]);

  for (const key of allKeys) {
    const fullPath = path ? `${path}.${key}` : key;
    if (!(key in a)) {
      diffs.push(`ADDED: ${fullPath} = ${JSON.stringify(b[key])}`);
    } else if (!(key in b)) {
      diffs.push(`REMOVED: ${fullPath}`);
    } else if (typeof a[key] === "object" && a[key] !== null
               && typeof b[key] === "object" && b[key] !== null) {
      diffs.push(...jsonDiff(a[key], b[key], fullPath));
    } else if (a[key] !== b[key]) {
      diffs.push(`CHANGED: ${fullPath}: ${JSON.stringify(a[key])} → ${JSON.stringify(b[key])}`);
    }
  }

  return diffs;
}

const result = jsonDiff(
  { user: { id: 42, name: "Alice", role: "admin" }, active: true },
  { user: { id: 42, name: "Alice" }, active: "true" }
);

console.log(result);
// ["REMOVED: user.role", "CHANGED: active: true → \"true\""]

This is far more useful than a raw boolean — you get the exact path and the exact values that changed.

Where types silently bite you

The most dangerous JSON diffs aren't missing keys — they're type changes. A value going from true (boolean) to "true" (string) looks identical in most log outputs but behaves completely differently in application logic.

Your comparison logic needs to be explicit about types. In the function above, a[key] !== b[key] catches this because JavaScript's strict equality distinguishes true from "true". In Python, watch out for integers and floats comparing as equal (1 == 1.0), which can mask precision changes that matter to downstream typed systems.

For a deeper look at the syntax issues and type mismatches that show up most often in real payloads, the 5 Common JSON Errors post on JSON Indenter's blog is worth a read — it covers the patterns that trip up developers most reliably.

When to reach for a library

For production use, libraries like deep-diff (Node.js) or deepdiff (Python) go further: they handle arrays intelligently, track moved elements, and give you structured change records you can iterate over. But for day-to-day debugging — the "why is this response different from yesterday?" question you face a dozen times a month — formatting both payloads consistently, validating them, and running a simple recursive diff gets you to the answer in under two minutes.

What's your go-to approach when two API responses look identical but aren't? Have you ever been burned by a boolean quietly becoming a string, or a key silently renamed in a schema update? Drop your war stories in the comments — I'd love to hear how others handle this.

Free tools used in this post:

JSON Formatter & Validator — instantly formats and beautifies JSON in your browser, client-side
JSON Validator Pro — lint and validate JSON with exact line-number error reporting
All tools — client-side, no sign-up, nothing leaves your browser

How to structure JSON for LLMs (and stop wasting tokens)

Tahmid — Sat, 18 Apr 2026 19:15:15 +0000

Most developers treat JSON as an afterthought when building LLM-powered apps. They dump raw API responses into prompts and wonder why the model hallucinates, misreads fields, or burns through tokens.

JSON structure is a first-class concern in AI engineering. Here's how to get it right.

The problem: LLMs don't read JSON like humans do

When you paste this into a prompt:

{"user":{"id":1,"name":"Alice","preferences":{"theme":"dark","notifications":true,"language":"en"}}}

The model tokenizes it character by character. Every {, ", :, and , is a token. Deeply nested structures force the model to maintain more working context just to understand the shape of the data — before it even processes the values.

The result: more tokens consumed, more room for misinterpretation, higher API costs.

Rule 1: Flatten before you prompt

Nested JSON is great for APIs. It's bad for prompts.

Before:

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

After (flattened):

{
  "user_name": "Alice",
  "user_age": 28
}

One level deep is almost always enough for LLM context. If the model needs to reason about relationships, describe them in natural language alongside the data — don't encode them in nesting.

Rule 2: Strip fields the model doesn't need

Every field in your JSON costs tokens. If the model doesn't need created_at, updated_at, internal_id, or _metadata — remove them before building the prompt.

const { created_at, updated_at, _metadata, ...relevant } = apiResponse;
const prompt = `Here is the user data: ${JSON.stringify(relevant)}`;

This alone can cut token usage by 20–40% on typical API responses.

Rule 3: Use TOON for large payloads

If you're passing payloads larger than ~500 tokens, consider TOON (Token-Oriented Object Notation). It's a compact alternative to JSON that strips redundant syntax while preserving structure.

JSON:

[
  {"name": "Alice", "role": "admin"},
  {"name": "Bob", "role": "editor"}
]

TOON:

name|role
Alice|admin
Bob|editor

Token reduction: 30–60% on typical datasets. The model reads it correctly because the structure is still unambiguous — just more compact.

Try it on your own payloads with the JSON to TOON converter. There's also a TOON to JSON converter for decoding the model's response back.

Rule 4: Use JSON Schema to enforce structured outputs

LLMs can return JSON — but without constraints, they hallucinate keys, change types, and add fields you didn't ask for.

The fix: define a schema and include it in your system prompt.

{
  "type": "object",
  "properties": {
    "sentiment": { "type": "string", "enum": ["positive", "negative", "neutral"] },
    "confidence": { "type": "number", "minimum": 0, "maximum": 1 },
    "summary": { "type": "string", "maxLength": 200 }
  },
  "required": ["sentiment", "confidence", "summary"]
}

Tell the model: "Respond only with a JSON object matching this schema. No explanation, no markdown."

Then validate the output with a JSON Schema validator before trusting it. This is especially critical in agentic workflows where one bad output poisons downstream steps. You can generate a schema automatically from any sample payload using the JSON Schema generator — useful as a starting point you can then tighten up.

Rule 5: Use Pydantic or Zod to validate at the boundary

Never trust raw LLM JSON output in production. Parse and validate it immediately.

Python (FastAPI / AI agents):

from pydantic import BaseModel

class SentimentResult(BaseModel):
    sentiment: str
    confidence: float
    summary: str

result = SentimentResult.model_validate_json(llm_output)

TypeScript (Next.js / tRPC):

import { z } from 'zod';

const SentimentResult = z.object({
  sentiment: z.enum(['positive', 'negative', 'neutral']),
  confidence: z.number().min(0).max(1),
  summary: z.string().max(200),
});

const result = SentimentResult.parse(JSON.parse(llmOutput));

Writing these by hand from a large JSON payload is tedious. The JSON to Pydantic and JSON to Zod generators handle it instantly — paste your payload, get the model.

Rule 6: Use TypeScript interfaces when working with typed LLM outputs

If you're building in TypeScript, generating interfaces from your JSON response shapes saves time and prevents drift between what the LLM returns and what your code expects.

// Generated from your actual LLM response shape
interface SentimentResponse {
  sentiment: 'positive' | 'negative' | 'neutral';
  confidence: number;
  summary: string;
}

The JSON to TypeScript converter generates these from any payload — useful when you're iterating quickly on prompt outputs and want the type system to catch regressions.

The full checklist

Before passing JSON to an LLM:

Flatten nested structures to one level where possible
Strip fields irrelevant to the task
Use TOON for payloads > 500 tokens
Define a JSON Schema for expected output
Validate output with Pydantic or Zod before use
Use TypeScript interfaces to catch output shape regressions

These aren't micro-optimisations. On high-volume AI apps, they compound into significant cost and reliability improvements.

What's your current approach to JSON in LLM workflows? Drop it in the comments — I'm curious how others handle this.

Free tools used in this post:

JSON to TOON — compress JSON for LLM context
TOON to JSON — decode TOON back to JSON
JSON Schema Generator — generate schemas from sample payloads
JSON to Pydantic — instant Python models
JSON to Zod — instant TypeScript validation schemas
JSON to TypeScript — generate interfaces from any payload
All tools — client-side, no sign-up, nothing leaves your browser

JWT security mistakes that will get you breached

Tahmid — Sat, 18 Apr 2026 19:05:55 +0000

JWTs are everywhere. Auth tokens, API keys, session management — if you're building web apps, you're almost certainly using them. They're also one of the most commonly misconfigured pieces of security infrastructure in production systems.

Here are the mistakes I see repeatedly, and exactly how to fix them.

Quick recap: what a JWT actually is

A JWT has three parts separated by dots:

header.payload.signature

Header — algorithm used to sign the token (HS256, RS256, etc.)
Payload — the claims (user ID, roles, expiry, etc.)
Signature — cryptographic proof the token hasn't been tampered with The payload is base64-encoded, not encrypted. Anyone who intercepts your token can read everything in it. This matters more than most developers realise.

If you want to see this in action, paste any token into a JWT decoder and read the payload in plain text — no tools, no secret needed.

Mistake 1: Using the `none` algorithm

This is the most catastrophic JWT vulnerability. Some libraries accept a token signed with alg: none — meaning no signature at all.

An attacker can craft a token like this:

// Header (base64 decoded)
{ "alg": "none", "typ": "JWT" }

// Payload (base64 decoded)
{ "sub": "1234", "role": "admin" }

If your server accepts it, the attacker just gave themselves admin access with no credentials.

Fix: Explicitly allowlist the algorithms your server accepts. Never allow none.

// Node.js / jsonwebtoken
jwt.verify(token, secret, { algorithms: ['HS256'] });

Mistake 2: Weak or hardcoded secrets

HS256 is a symmetric algorithm — the same secret signs and verifies tokens. If your secret is weak or leaked, every token ever issued is compromised.

Common offenders:

secret
password
jwt_secret
mysecretkey
your-256-bit-secret   ← literally from the JWT.io example

Fix: Generate secrets with sufficient entropy and store them in environment variables, never in code.

# Generate a strong secret
node -e "console.log(require('crypto').randomBytes(64).toString('hex'))"

For production systems with multiple services, prefer RS256 (asymmetric) — the private key signs, the public key verifies. A compromised verification service can't forge tokens. You can test tokens signed with different algorithms using the JWT encoder to understand exactly what gets embedded.

Mistake 3: Storing JWTs in localStorage

localStorage is accessible to any JavaScript running on your page. A single XSS vulnerability — in your code, a dependency, or a third-party script — exposes every stored token.

Fix: Store JWTs in HttpOnly cookies. They're invisible to JavaScript entirely.

res.cookie('token', jwt, {
  httpOnly: true,    // not accessible via JS
  secure: true,      // HTTPS only
  sameSite: 'strict' // CSRF protection
});

Yes, this requires handling CSRF. That's a better problem to have than XSS token theft.

Mistake 4: No expiry — or expiry that's too long

A JWT with no exp claim is valid forever. If it's leaked, stolen, or the user's account is compromised, you have no way to invalidate it short of rotating your signing secret (which invalidates every token).

Fix: Set short expiry for access tokens, longer for refresh tokens.

const accessToken = jwt.sign(payload, secret, { expiresIn: '15m' });
const refreshToken = jwt.sign(payload, secret, { expiresIn: '7d' });

15 minutes for access tokens is a common production standard. Refresh tokens should be rotated on use and stored server-side so they can be revoked.

Mistake 5: Putting sensitive data in the payload

The payload is not encrypted. It's trivially decoded by anyone with the token:

echo "eyJ1c2VyIjoiYWxpY2UiLCJwYXNzd29yZCI6InNlY3JldCJ9" | base64 -d
# {"user":"alice","password":"secret"}

I've seen production tokens containing passwords, full PII, credit card fragments, and internal system details. All readable by anyone who intercepts the token. Try it yourself — paste that string into a JWT decoder and see exactly what's exposed.

Fix: Put only the minimum identifying information in the payload.

{
  "sub": "user_abc123",
  "role": "admin",
  "exp": 1735689600
}

Look up everything else server-side using the sub claim. If you need the payload encrypted, use JWE (JSON Web Encryption) — a different standard entirely.

Mistake 6: Not validating claims server-side

Libraries verify the signature automatically — but claim validation is on you.

// Bad — only verifies signature
const decoded = jwt.verify(token, secret);

// Good — verify signature AND validate claims
const decoded = jwt.verify(token, secret, { algorithms: ['HS256'] });

if (decoded.exp < Date.now() / 1000) throw new Error('Token expired');
if (decoded.iss !== 'https://yourapp.com') throw new Error('Invalid issuer');
if (decoded.aud !== 'your-api') throw new Error('Invalid audience');

Always validate exp, iss (issuer), and aud (audience) explicitly — especially if tokens from multiple issuers could reach your API.

Mistake 7: No token revocation strategy

JWTs are stateless by design — once issued, they're valid until expiry. But what happens when:

A user logs out
An account is compromised
A user's role changes mid-session If you're relying purely on token expiry, a stolen 15-minute token is valid for up to 15 minutes after the breach is detected.

Fix: Maintain a server-side revocation list (denylist) for sensitive operations.

// On logout
await redis.set(`revoked:${jti}`, '1', 'EX', 900); // expire after token TTL

// On verify
const isRevoked = await redis.get(`revoked:${decoded.jti}`);
if (isRevoked) throw new Error('Token revoked');

Add a jti (JWT ID) claim — a unique identifier per token — so you can target specific tokens for revocation without rotating your secret.

The JWT security checklist

Explicitly allowlist algorithms — never allow none
Use strong, randomly generated secrets (64+ bytes)
Prefer RS256 for multi-service architectures
Store tokens in HttpOnly cookies, not localStorage
Set short expiry on access tokens (15 minutes)
Put only non-sensitive identifiers in the payload
Validate exp, iss, and aud claims explicitly

- Implement token revocation with a `jti` denylist

JWTs are a solid auth primitive when implemented correctly. The problems almost always come from default configurations and library trust — not the spec itself.

What JWT issue have you encountered in production? Drop it in the comments.

Free tools used in this post:

JWT Decoder — inspect any token without a secret
JWT Encoder — generate and sign JWTs for testing
All JSON & JWT tools — everything runs client-side, nothing leaves your browser

5 JSON tricks most developers don't use

Tahmid — Sat, 18 Apr 2026 18:01:11 +0000

JSON is everywhere, but most developers only use JSON.parse() and JSON.stringify(). Here are a few tricks worth knowing.

1. Pretty-print in one line

console.log(JSON.stringify(data, null, 2));

The third argument is your indent size. Instant readability.

2. Filter keys on stringify

JSON.stringify(user, ['name', 'email'], 2);

Pass an array of keys to only include those fields. Great for logging without exposing sensitive data.

3. JSONPath for deep queries

Instead of chaining .map() and .filter(), JSONPath lets you query nested JSON like a database:

$.users[?(@.age > 30)].name

4. Auto-repair broken JSON

LLMs often return slightly malformed JSON — trailing commas, single quotes, missing brackets. Instead of debugging it manually, a repair function can fix most common issues automatically.

5. Reduce LLM token usage with compact formats

If you're passing large JSON payloads as context to GPT or Claude, consider stripping whitespace at minimum. Better yet, look into TOON (Token-Oriented Object Notation) — a compact alternative that cuts token count by 30–60% without losing structure.

I built jsonindenter.com as a free client-side toolkit that covers all of the above — JSONPath tester, JSON repair, TOON converter, Zod/Pydantic generators, JWT tools, and more. No sign-up, no ads, your data never leaves your browser.

What JSON tricks do you swear by? Drop them in the comments 👇

DEV Community: Tahmid

Why Your JSON Keeps Breaking (And How to Fix It Fast)

The Four Most Common JSON Errors

1. Trailing Commas

2. Single Quotes Instead of Double Quotes

3. Comments Embedded in JSON

4. JavaScript-Only Values

Stop Hunting for Errors by Eye

Comparing Two JSON Responses

Minifying for Production

A Practical Debugging Workflow

The Bigger Picture

How to Compare Two JSON Objects and Spot the Differences Instantly

Step 1: Format both objects identically

Step 2: Validate before you compare

Step 3: Compare programmatically when you need precision

Where types silently bite you

When to reach for a library

How to structure JSON for LLMs (and stop wasting tokens)

The problem: LLMs don't read JSON like humans do

Rule 1: Flatten before you prompt

Rule 2: Strip fields the model doesn't need

Rule 3: Use TOON for large payloads

Rule 4: Use JSON Schema to enforce structured outputs

Rule 5: Use Pydantic or Zod to validate at the boundary

Rule 6: Use TypeScript interfaces when working with typed LLM outputs

The full checklist

JWT security mistakes that will get you breached

Quick recap: what a JWT actually is

Mistake 1: Using the none algorithm

Mistake 2: Weak or hardcoded secrets

Mistake 3: Storing JWTs in localStorage

Mistake 4: No expiry — or expiry that's too long

Mistake 5: Putting sensitive data in the payload

Mistake 6: Not validating claims server-side

Mistake 7: No token revocation strategy

The JWT security checklist

- Implement token revocation with a jti denylist

5 JSON tricks most developers don't use

1. Pretty-print in one line

2. Filter keys on stringify

3. JSONPath for deep queries

4. Auto-repair broken JSON

5. Reduce LLM token usage with compact formats

Mistake 1: Using the `none` algorithm

- Implement token revocation with a `jti` denylist