Frequently Asked Questions

Yes — every tool on this site runs entirely in your browser. JSON you paste, upload, or drop onto these pages is processed by JavaScript on your device. The website's server never sees your data because there is no server-side processing. To verify: open your browser's Developer Tools, switch to the Network tab, and use any tool. You'll see zero outbound requests carrying your data.

Completely free. No signup, no paywall, no usage limits, no premium tiers. The site is supported by ads in the page header and footer area — never inside the tool itself. Every feature is available to everyone, every time.

No JSON data is logged or stored. We use Google Analytics for anonymous pageview metrics (page URL, country-level location, browser type — nothing about the contents of your tool inputs) and Google AdSense for advertising. Neither service has access to what you paste into the tools. Full details on our privacy page.

Yes. Once a tool page has loaded, you can disconnect from the internet and it keeps working. All parsing, formatting, validation, and conversion logic is JavaScript that executes locally. For truly air-gapped use, save the page with Ctrl+S / Cmd+S and you'll have a fully self-contained copy.

Yes — JWTs and API responses both stay in your browser. We specifically built the JWT decoder to decode tokens client-side without ever submitting them. We deliberately don't offer signature verification because that would require collecting your secret keys, and we won't ask for those.

JSON (JavaScript Object Notation) is a way to write down structured data so that any program can read it. It uses three main shapes: objects (key-value pairs wrapped in {}), arrays (lists wrapped in []), and primitive values (strings, numbers, booleans, null). Despite the JavaScript in the name, JSON is supported by every modern programming language. It's the default data format for most web APIs and many configuration files.

JSON is text — a specific syntax for representing data that any language can parse. JavaScript objects are live in-memory data structures that include methods, prototypes, and references. JSON is a subset: any valid JSON parses into a JavaScript object, but most JavaScript objects can't be represented as JSON (functions, undefined values, circular references, Symbol keys, and Dates all fail to serialize).

Yes — both keys and string values are case-sensitive. "name" and "Name" are different keys. This is a common source of bugs when consuming JSON: an API documents a field as customerId but actually returns customerID, and your code silently fails to find it. Pretty-printing the JSON and inspecting it with the formatter is the fastest way to catch these mismatches.

Six types: string (double-quoted text), number (integer or floating-point), boolean (true or false), null, object (unordered key-value pairs), and array (ordered list). Notably missing: dates (use ISO 8601 strings), binary data (use Base64-encoded strings), and big integers above 2^53 (use strings to preserve precision).

No. Standard JSON does not support comments — neither // line comments nor /* block comments */. There are non-standard supersets that do: JSONC (JSON with Comments, used by VS Code) and JSON5 (a more flexible superset). If you need comments in a config file, choose one of those — but the receiving tool must support the format. Our tools strictly validate against standard JSON.

The most common culprits, in order of frequency: (1) trailing commas — a comma right before a closing brace or bracket; valid JavaScript but not JSON. (2) single quotes instead of double quotes — JSON requires double quotes everywhere. (3) unquoted object keys — every key must be in double quotes. (4) comments — JSON has no comment syntax. (5) invisible characters like a UTF-8 BOM at the start, or smart quotes pasted from a word processor instead of straight ASCII quotes.

The error message names the specific token the parser didn't expect, and our tools also report the line and column. Common cases: 'Unexpected token }' usually means a missing comma between properties or a trailing comma. 'Unexpected token :' usually means an unquoted key. 'Unexpected end of JSON input' means a missing closing brace or bracket. Look at the line/column the error points to and the character just before it — that's almost always where the real problem is.

Historical reasons. JSON was designed in 2001 as a strict subset of JavaScript object literal syntax, and at the time, JavaScript itself was inconsistent about trailing commas (different engines treated them differently). Douglas Crockford chose strictness for maximum portability. Modern JavaScript allows trailing commas, but JSON's spec was already in wide use and couldn't be loosened without breaking implementations. JSON5 and JSONC both allow trailing commas — switch to those if you need them.

Most JSON parsers hit the call stack limit around 500-2000 levels deep, depending on the runtime. This usually indicates a bug in the program generating the JSON — real data rarely needs more than 10-20 levels of nesting. If your structure is genuinely that deep, consider flattening it (use composite keys like "a.b.c.d" instead of {a:{b:{c:{d:1}}}}) or splitting it across multiple documents linked by ID.

Comfortably up to 50 MB on modern browsers. Between 50 MB and 100 MB, expect noticeable lag — the tools still work, but pasting and formatting take longer. Above 100 MB, the browser's memory limits become a problem and we'd recommend a command-line tool like jq instead, which can stream gigabyte-scale files.

Browser JavaScript runs on a single thread. While the tool is parsing and formatting, the UI can't repaint or respond. For files under 10 MB, this is imperceptible. For larger files, you'll see the tab become unresponsive for a few seconds. If your file is too big to handle comfortably in the browser, use jq or a language-specific streaming parser.

Faster than most online formatters because we use the browser's native JSON.parse and JSON.stringify rather than a JavaScript reimplementation. Native parsing is typically 5-10x faster than a JS-implemented parser. For a 10 MB JSON file, formatting completes in well under a second on modern hardware.

Not currently. We strictly validate standard JSON per RFC 8259. JSON5 allows comments, trailing commas, unquoted keys, and other relaxations; JSONC (used in VS Code config files) is essentially JSON5 lite. Native JSON5/JSONC support is on our roadmap — for now, strip comments and convert single quotes to double quotes before pasting.

We deliberately don't store anything server-side, so there's no shareable URL with your data baked in. To share, copy the formatted JSON and paste it into a gist (gist.github.com), Pastebin, or any paste service. Avoid pasting sensitive JSON to public services — for that, share via a private channel.

No, and intentionally so. The value of this site is browser-side processing without an API call. For programmatic use, every language has built-in JSON support: JSON.stringify(obj, null, 2) in JavaScript, json.dumps(obj, indent=2) in Python, json.MarshalIndent in Go, serde_json::to_string_pretty in Rust. For CLI work, jq is the standard.

Functionally similar — all of them format, validate, and convert JSON. The differences worth knowing: (1) most competitor sites send your JSON to their server for processing; ours doesn't. (2) Our error reporting is line/column precise. (3) Our interface is uncluttered with no ads inside the tool itself. (4) The site loads faster because we don't use heavy front-end frameworks. If privacy and speed matter to you, we'd argue ours is the better choice.

JSON Schema is a way to describe the structure of JSON data — required fields, types, allowed values, regex patterns, ranges. Think of it as a type system for JSON. Use it when you need to validate inputs (incoming API requests), document outputs (API responses), generate type definitions, or auto-generate tests. Our JSON Schema Validator handles this. JSON Schema is the foundation of OpenAPI and AsyncAPI.

JSONPath is a path query language for JSON — like XPath for XML. $.users[*].email extracts every user's email. jq is a more powerful language that can also transform and aggregate data, not just select. For simple extraction, JSONPath is easier to learn; for complex pipelines, jq is more capable. Our JSONPath tester uses the Goessner dialect, supported by most JSON libraries.

Both operate on the same data — only the whitespace differs. Formatting (also called pretty-printing or beautifying) adds indentation, newlines, and spaces so humans can read the JSON. Minification removes all unnecessary whitespace to produce the smallest valid representation, typically 30-60% smaller. Use formatting during development; use minification for production APIs, storage, and over-the-wire transmission.

Depends on who's editing them. YAML is easier to write by hand (less punctuation, comments allowed) and is the standard for Kubernetes, GitHub Actions, Docker Compose, and Ansible. JSON is easier to generate programmatically and faster to parse. For configs that humans edit frequently, YAML wins. For configs that programs generate and consume, JSON wins. Our JSON ↔ YAML converter lets you switch between them.

Yes — our JSON to CSV converter flattens nested objects using dot notation. {"user":{"name":"Alice"}} becomes a CSV column called user.name. Arrays inside objects are preserved as JSON strings in a single cell, keeping the information intact without breaking the row-to-row correspondence.

Use our JSON Diff tool. It does semantic comparison — key order doesn't matter, whitespace doesn't matter, only real data differences are reported. Each difference is labeled with a JSON path like $.users[2].email so you can navigate directly to it. This is much more accurate than text-based diff for JSON.

Fully supported. JSON strings can contain any Unicode character including emoji, CJK characters, and right-to-left scripts. Our tools use the browser's native parser which is fully Unicode-aware. Characters outside the Basic Multilingual Plane (like emoji) are typically represented as surrogate pairs in JSON — both forms (raw character and \uD83D\uDE00 escape) round-trip correctly.

JavaScript stores all numbers as 64-bit IEEE 754 floats, which means integers larger than 2^53 (about 9 quadrillion) lose precision when parsed. This is a JavaScript limitation, not a tool limitation. If your JSON contains huge integer IDs like Twitter snowflake IDs or 64-bit database IDs, store them as strings ("id": "123456789012345678") to preserve precision.

JSON has no native date type — dates are conventionally stored as ISO 8601 strings ("2026-05-13T12:34:56Z") or Unix timestamps (1747140896). The formatter preserves whichever representation you use as plain strings or numbers. For JWT tokens, our JWT decoder automatically converts Unix timestamps in iat, exp, and nbf claims to human-readable times.

JSON technically allows duplicate keys — the spec doesn't forbid them, though it warns that behavior is undefined. Most parsers silently keep only the last value for a duplicate key, which is what JavaScript's JSON.parse does. If you see this happening, the original data has duplicate keys; check the source. Our tools don't flag duplicates because they're valid JSON, but they're almost always a bug.

Not currently — our Schema validator requires you to paste both the schema and the data. We don't fetch external $ref URLs because that would require network requests, which contradicts our privacy-first design. To validate against a schema-by-URL, inline the schema first with a tool like json-dereference-cli.