How to format and validate JSON without uploading it anywhere

Guo — Sat, 12 Sep 2026 12:06:27 +0000

A JSON blob is often easiest to read after it has been formatted. That sounds harmless until the blob is an API response with customer data, a production configuration file, or a test fixture copied from somewhere you should not casually share.

The usual workflow is simple: paste it into a formatter, make it readable, copy it back.

The problem is that the formatter may be another service in the data path.

For ordinary sample data, that may not matter. For production payloads, credentials, tokens, private URLs, or customer records, it should make you stop before pasting. A local formatter is useful because parsing and formatting can happen in the browser instead of requiring a request to a server. It is still not a license to paste secrets everywhere. Clipboard history, browser extensions, screenshots, and the system you later paste into remain part of the risk.

This article covers a practical local JSON workflow, what browser validation actually proves, and where its limits begin.

Start with strict JSON, not JavaScript-like JSON

JSON and JavaScript object literals look similar. They are not the same format.

This is valid JavaScript:

const settings = {
  theme: 'dark',
  retryCount: 3,
};

It is not valid JSON. JSON requires double-quoted property names and string values. It also does not allow trailing commas.

{
  "theme": "dark",
  "retryCount": 3
}

That distinction matters when you are preparing data for an API, a package.json file, or another strict JSON consumer. The JSON specification defines a limited data model: objects, arrays, strings, numbers, booleans, and null. It does not include comments, functions, undefined, NaN, Infinity, or JavaScript shorthand syntax. RFC 8259 is the useful reference when a format dispute turns into a production bug.

Do not use eval() to "fix" JSON-like text. It turns data handling into code execution. If the input is JSON5, YAML, or a JavaScript configuration module, identify that format and use a parser intended for it.

What formatting does, and what it does not do

A formatter normally does two things:

Parse the text into a value.
Serialize that value again with chosen indentation.

In browser JavaScript, that often means JSON.parse() followed by JSON.stringify(). MDN documents both APIs and their edge cases, including serialization behavior for values that JSON cannot represent directly. JSON.parse() and JSON.stringify() are worth reading if you regularly move data between JavaScript and APIs.

Formatting makes structure visible:

{"service":"billing","enabled":true,"limits":{"daily":250,"monthly":5000}}

becomes:

{
  "service": "billing",
  "enabled": true,
  "limits": {
    "daily": 250,
    "monthly": 5000
  }
}

That makes missing brackets, unexpected nesting, and confusing field names easier to spot.

It does not prove that the data is correct for your application.

A valid JSON document can still have a wrong field name, an expired identifier, a string where an API expects a number, or an unsafe permission setting. Syntax validation is the first check, not the last one.

A safer local workflow

For non-sensitive JSON, I use this sequence:

Remove secrets before copying anything. That includes API keys, bearer tokens, passwords, signed URLs, session values, and customer data.
Validate the original text before changing it.
Format it only after it passes strict parsing.
Compare important values against the source, especially IDs, URLs, amounts, flags, and ordered arrays.
Test the final JSON with the actual destination system.

The first step is not optional just because a tool claims local processing. OWASP advises against placing sensitive data in browser storage, and browser-side handling has risks that go beyond network transmission. OWASP Web Storage guidance

For a browser-based workspace, I built ToolExo JSON Formatter and Validator. It uses the browser's strict JSON parser to validate, format, minify, or optionally sort object keys. It reports invalid syntax instead of silently adding quotes, removing comments, or guessing what malformed input was meant to say.

That last part is deliberate. Silent repair can hide the bug that generated the bad JSON in the first place.

Common errors worth recognizing

Trailing commas

This is one of the most common cases where JavaScript habits leak into JSON:

{
  "environment": "staging",
  "debug": false,
}

The comma after false is invalid because no next property follows it.

{
  "environment": "staging",
  "debug": false
}

Single quotes

JSON strings use double quotes only.

{ 'status': 'ready' }

Correct JSON:

{ "status": "ready" }

Unquoted property names

This is valid in a JavaScript object literal but invalid in JSON:

{ timeout: 3000 }

Correct JSON:

{ "timeout": 3000 }

Comments

JSON does not support comments:

{
  // used by the nightly job
  "enabled": true
}

If the destination expects JSON, move that explanation into documentation or a field with an agreed meaning. Do not assume a comment-tolerant editor means the receiving system will accept it.

Be careful when sorting keys

Sorting object keys can make reviews and diffs easier. It should not change the meaning of a normal JSON object, but it changes the text.

That matters if another system signs the original bytes, compares snapshots as text, or expects a defined canonicalization scheme. Array order is different. Arrays are ordered, so a formatter should not reorder their elements just because it can sort object keys.

If you are about to replace a file used in production, keep the original, save the formatted version as a new file, and test the new file where it will actually run.

Large integers and duplicate keys need extra attention

JavaScript numbers use IEEE 754 floating-point representation. A JSON integer may be syntactically valid but lose precision when parsed into a JavaScript Number. For identifiers, account numbers, or exact counters, use a documented string representation if precision matters.

Duplicate object keys are another interoperability trap:

{
  "region": "us-east-1",
  "region": "eu-west-1"
}

Different parsers can handle duplicate names differently. Many JavaScript workflows keep the later value, but relying on that behavior makes the data ambiguous. Reject or fix duplicate names at the source.

Formatting is a debugging aid, not a schema

A JSON formatter answers a narrow question: "Can this text be parsed as JSON?"

It cannot answer:

Does this payload match the API schema?
Are all required fields present?
Is this user allowed to submit the request?
Does the number use the correct unit?
Is the URL safe to fetch?
Does the data make sense for the business rule?

Use schema validation, server-side authorization, field validation, and integration tests for those questions.

Formatting earns its place earlier in the workflow. It makes a compact response readable, exposes a syntax error before you chase the wrong problem, and helps you review the shape of data without sending it to a third-party formatter.

That is enough to make it a useful tool. It just should not be confused with a security boundary or a full validation system.

DEV Community: Guo