Format, beautify, pretty print, validate or convert JSON payloads

Return a top-level object rather than a bare array, so you can add fields later without breaking clients. Keep a consistent envelope — for example a data field plus optional meta and links for pagination — use one key-casing convention throughout, send the Content-Type: application/json header, and pair the body with the correct HTTP status code instead of signalling failures only inside the payload.

GraphQL rides on JSON: the request body is a JSON object with a query string and optional variables, and the response is a JSON object with a data key plus an errors array when something fails. Unlike REST, the client chooses exactly which fields come back, so the response shape mirrors the query — and most GraphQL servers return HTTP 200 even on errors, so inspect the errors array rather than trusting the status code.

JSON has no native date type, so serialise timestamps as ISO 8601 strings in UTC (for example 2026-06-14T09:30:00Z) or as a numeric epoch — and document which you use. ISO 8601 is human-readable and sorts lexicographically; epoch milliseconds are compact and unambiguous. Avoid locale-specific formats, and represent money as integer minor units (cents) or decimal strings to avoid floating-point rounding.

JavaScript parses JSON numbers as IEEE-754 doubles, which represent integers exactly only up to 2^53 − 1. Larger 64-bit values such as database bigints or snowflake IDs silently corrupt beyond that point. Transmit them as strings, or parse with a BigInt-aware library such as json-bigint. Pretty-printing a suspect payload here is a fast way to check whether an ID has already been mangled.

Return a consistent, machine-readable error object: a stable code for programs, a human-readable message, and a details or errors array for field-level validation problems. The application/problem+json format from RFC 9457 (which replaced RFC 7807) is a good ready-made shape. Always set an appropriate 4xx or 5xx status so clients don't have to parse the body just to learn that the call failed.

Either works — consistency matters far more than the choice. JavaScript, TypeScript, and most GraphQL schemas lean toward camelCase; Python, Ruby, and many SQL-backed APIs use snake_case. Pick one convention per API and enforce it in your serializer, because mixing the two is a common source of bugs and clumsy client code.

JSON Lines, also called NDJSON, puts one complete JSON object on each line instead of wrapping everything in a single array. That lets you stream and append records, process huge datasets without loading them entirely into memory, and tail logs in real time — which is why data warehouses like BigQuery and many log pipelines use it. Prefer it whenever one top-level array would be too large to parse at once.

Syntax validation, which is what this tool does, only confirms that a document parses; it does not confirm the right fields and types are present. For that, define a JSON Schema and validate with a library such as Ajv, or describe your API with OpenAPI and generate validators and types from it. Schemas also act as living documentation and enable contract testing between services.

Never run eval() on JSON — always use JSON.parse. Guard against prototype pollution from crafted __proto__ or constructor keys when you merge parsed objects, cap the accepted payload size to blunt denial-of-service attempts, and validate or escape values before using them in SQL, HTML, or shell contexts. Keep secrets out of any JSON that reaches the client. Because this tool runs entirely in your browser, you can inspect sensitive payloads without sending them anywhere.

Turn on gzip or Brotli first — JSON's repetitive keys compress extremely well, and that usually beats manual tweaks. Beyond compression, paginate or let clients select fields (sparse fieldsets, or GraphQL field selection), omit null and default values, and shorten needlessly verbose keys. For very hot internal paths where size and speed dominate, consider a binary format instead.

Keep JSON for public APIs and anything you debug by eye — readability is its main advantage. Switch to Protocol Buffers, Avro, or MessagePack for high-throughput, service-to-service traffic, where payloads are typically several times smaller and parse faster, in exchange for a required schema and bytes humans cannot read. Plenty of systems use both: a binary format internally and JSON at the public edge.

Standard JSON allows no comments and no trailing commas, so a tsconfig-style file with // notes is really JSONC, and one with trailing commas or unquoted keys is JSON5 — both need their own parsers and fail strict validation. If the validator here rejects your config file, that mismatch is usually why. Keep the comment-friendly dialects for human-authored config, and use strict JSON for data sent over the wire.

Paste a raw response, upload a .json file, or fetch a URL directly, then click Validate to catch malformed payloads and Pretty to make a minified blob readable. Convert an array of records to CSV to scan it in a spreadsheet, or to YAML or XML when another system needs that format. Everything runs locally in your browser, so it stays safe for production payloads and access tokens.