JSON-koodaus / -purku

JSON escape and unescape online — free, private, instant

This JSON escape tool turns any text into a JSON-safe string and converts escaped strings back to plain text — both directions in one place, instantly, and entirely in your browser. Paste your content, pick Escape or Unescape, and copy the result. Nothing to install, nothing to sign up for. Because every conversion runs locally, your data never leaves your device — safe for API payloads, access tokens, passwords, and any confidential text you wouldn't want uploaded to a server.

It's the fastest way to escape a JSON string for an API payload, drop a multi-line snippet into a config file, or recover the original text from an escaped value you found in a log. The conversion uses the browser's native JSON engine — not a hand-rolled regex — so the output matches what JSON.stringify produces in JavaScript and what every spec-compliant parser across Python, Go, Java, and Ruby expects.

What needs escaping in JSON — and what doesn't

Only a small set of characters has special meaning inside a JSON string. The double quote " must become \", the backslash \ must become \\, and the whitespace control characters become \b, \f, \n, \r and \t. Any remaining control character below U+0020 is written as a \uXXXX escape. Everything else — letters, digits, single quotes, hyphens, and ordinary punctuation — passes through untouched. This is a common source of confusion: single quotes don't need escaping in JSON because JSON strings use double quotes as delimiters, never single quotes.

Getting one of these wrong is why JSON fails to parse. An unescaped double quote ends the string early, causing an "Unexpected token" error. A lone backslash is read as the start of an escape sequence — if the next character isn't a valid escape character, the parse fails. A literal newline inside a string is simply not allowed by the spec. Paste the broken value into Escape mode and the tool returns a correctly escaped version in under a second.

Escape, unescape, stringify — what each mode does

Escape mode encodes your text so it can live inside a JSON string. By default you get just the escaped contents, ready to paste between your own quotes; switch on Wrap in quotes and you get a complete quoted JSON string value — exactly what JSON.stringify() produces. That's the difference between escaping (encoding the special characters) and stringifying (encoding and wrapping in quotes). Both produce output that every standard JSON parser will accept.

Unescape mode does the reverse, interpreting \", \\, \n, \t and \uXXXX back into the characters they represent. It accepts input with or without the surrounding quotes and reports a clear error on malformed escapes. The Swap button flips the output back into the input under the opposite mode, so round-tripping is one click — escape something, verify the output, swap, and confirm you get back the original.

Unicode, backslashes, Windows paths, and HTML-safe output

JSON stores Unicode as raw UTF-8 by default, but sometimes you need pure ASCII. Turn on Escape non-ASCII (\uXXXX) and every accented letter or emoji becomes a \uXXXX sequence — é becomes \u00e9 and 😀 becomes the surrogate pair \ud83d\ude00. This keeps older parsers and ASCII-only config files working correctly with no data loss.

For Windows file paths and regex patterns, the backslash doubling is automatic: paste C:\Users\me and the tool outputs C:\\Users\\me. For HTML embedding, the Escape forward slashes option rewrites / as \/ so that a closing script tag inside a string value can't break out of the surrounding HTML — still valid JSON that parses identically, but safe to inline in a server-rendered page. Tools like JSONLint can confirm the escaped output is valid before you deploy.

How this compares to JSONLint, jsonformatter.org, VS Code, and server-side tools

JSONLint validates whether a complete JSON document is well-formed. jsonformatter.org pretty-prints JSON for readability. VS Code's built-in formatter handles indentation and syntax highlighting but doesn't escape or unescape individual string values. None of these fill the gap this tool covers: fixing a single string that contains special characters. Use jsonformatter.org to format; JSONLint to validate; VS Code to work with your full file; this tool to fix string values that break parsers.

Server-side JSON escape tools exist but come with a tradeoff: your text leaves your device. If you're working with API keys, passwords, private configuration, or user data, sending that to an external server is unnecessary risk. This tool processes everything client-side — nothing is uploaded, logged, or stored. It works offline once loaded, so you can use it without any network connection. No account to create, no rate limit, no file size cap.

The JSON specification: RFC 8259 and the rules it sets

JSON was formalized by Douglas Crockford in the early 2000s and first standardized as RFC 4627 in 2006. It was revised by RFC 7159 in 2013 and then by RFC 8259 in 2017, which is the current authoritative standard. The specification defines exactly six value types: object (an unordered collection of key–value pairs), array (an ordered sequence), number, string, boolean (the literals true and false), and null. Every conforming JSON parser in every programming language is built around these six types — no more, no less.

JSON string rules under RFC 8259 are precise and non-negotiable. Strings must be delimited by double quotes — single quotes are a syntax error, not an alternative. Control characters in the range U+0000 through U+001F — including tab, newline, carriage return, and backspace — cannot appear literally inside a string; they must be represented as escape sequences. RFC 8259 specifies exactly seven mandatory escape sequences: \" for double quote, \\ for backslash, \/ for forward slash (optional but permitted), \b for backspace, \f for form feed, \n for newline, \r for carriage return, and \t for tab. Any Unicode code point may also be encoded as \uXXXX using four hexadecimal digits; characters outside the Basic Multilingual Plane use a UTF-16 surrogate pair written as two consecutive \uXXXX sequences.

One important clarification from RFC 8259: JSON text exchanged between systems that are not part of a closed ecosystem must be encoded in UTF-8. The BOM (byte order mark, U+FEFF) must not appear at the start of a JSON text. These requirements close off many historical ambiguities around character encoding that caused interoperability problems in the years between RFC 4627 and RFC 8259. When a JSON parser reports a character encoding error rather than a parse error, it is typically rejecting input that violates this UTF-8 mandate.

JSON vs JavaScript object literals: similar syntax, different rules

The most persistent misconception about JSON is that it is JavaScript. It is not. JSON is a language-independent data interchange format that happens to share surface-level syntax with JavaScript object literals — but the two have meaningful differences. In JSON, all keys and all string values must use double quotes. JavaScript object literals allow unquoted keys ({ foo: 1 }) and single-quoted strings ('hello'); both are syntax errors in JSON. JSON does not allow trailing commas after the last item in an array or object — [1, 2, 3,] is invalid JSON even though modern JavaScript engines accept it. JSON does not support comments of any kind, even though comments are legal JavaScript. This trips up developers who try to annotate configuration files with // or /* */.

JSON also has no representation for several JavaScript primitives. The value undefined does not exist in JSON — JSON.stringify() drops object properties whose values are undefined rather than serializing them. The special numeric values Infinity, -Infinity, and NaN cannot be represented in JSON; JSON.stringify() converts them to null. Date objects are serialized to their ISO 8601 string representation (e.g., "2024-01-15T09:30:00.000Z") — the parser that reads them back receives a string, not a Date, unless a reviver function reconstructs the object. These silent conversions are a common source of subtle data loss bugs when developers assume JSON is a lossless round-trip format for all JavaScript values.

The gap between JSON and JavaScript syntax is precisely why JSONC (JSON with Comments) was introduced. VS Code uses JSONC for its settings.json, launch.json, tasks.json, and tsconfig.json files, pre-processing out comments before parsing the remainder as standard JSON. JSONC is not an official standard — it is a pragmatic extension for human-edited config files where the ability to annotate choices outweighs strict interoperability.

JSON5, HJSON, TOML, and YAML: when JSON isn't enough

The strictness that makes JSON ideal for machine-to-machine data exchange makes it frustrating for human-authored config files. Several formats have emerged to address this. JSON5 (2012) is the most conservative extension: it adds single-quoted strings, unquoted object keys, trailing commas, C-style comments (// and /* */), hexadecimal number literals (0xFF), and multi-line strings using backslash continuation. JSON5 is a superset of JSON — all valid JSON is valid JSON5 — and it is used in some Babel and ESLint configuration files. HJSON (Human JSON) goes further, adding multi-line strings without escape sequences and hash-style comments, and is used in some CLI tooling ecosystems.

TOML (Tom's Obvious Minimal Language) takes a different approach entirely, using INI-like syntax that is not related to JSON at all. TOML excels at hierarchical configuration and is the format behind Rust's Cargo.toml and Python's pyproject.toml. YAML occupies a different position: YAML 1.2 is a superset of JSON, meaning every valid JSON document is valid YAML, but YAML extends JSON with anchors, aliases, block scalars, and type tags. YAML is widely used in CI/CD pipelines (GitHub Actions, GitLab CI) and Kubernetes manifests. The tradeoff across all these formats is consistent: JSON is the simplest format to parse correctly — its grammar fits on one page — which is why it dominates APIs and data exchange, while TOML and YAML win for config files that humans write and maintain.

For escaping purposes, only JSON itself matters — JSON5, HJSON, TOML, and YAML all have their own string escaping rules that partially overlap with JSON but diverge in important ways. A string correctly escaped for JSON will parse correctly in any JSON5 parser, but the reverse is not true. When building APIs, log pipelines, or inter-service communication, always target strict JSON (RFC 8259) rather than any superset format, and use a tool or library function to handle escaping rather than doing it by hand.

JSON parsing and serialization: JavaScript, Python, and the integer precision trap

Every major language ships a JSON library. In JavaScript, JSON.stringify(value, replacer, space) serializes a value to a JSON string. The optional replacer argument is either an array of property names to include or a function that can transform values during serialization — useful for filtering out sensitive fields or converting non-serializable types. The space argument controls pretty-printing: pass a number for that many spaces of indentation, or a string (commonly "\t") to use tabs. JSON.parse(text, reviver) parses a JSON string back to a JavaScript value. The optional reviver function receives each key–value pair during parsing and can transform values — a common use case is reconstructing Date objects from ISO 8601 strings. In Python, the equivalent functions are json.dumps() and json.loads(). json.dumps() accepts indent for pretty-printing, ensure_ascii=False to allow non-ASCII characters to appear as-is rather than as \uXXXX escapes, and a default function for serializing custom types that the library does not know how to handle.

A notorious edge case that caught major production systems off guard is the integer precision problem. The JSON specification places no upper bound on the size of numbers, but JavaScript represents all numbers as IEEE 754 double-precision floating-point values, which can only represent integers exactly up to 2⁵³ − 1 (9,007,199,254,740,991). Beyond that limit, consecutive integers map to the same float and become indistinguishable. Twitter's tweet IDs exceeded this threshold as the platform grew, causing JavaScript clients to silently corrupt IDs when parsing API responses — a tweet with one ID would be treated as a different tweet. Twitter's fix was to send id_str (a string representation) alongside the numeric id field. Modern JavaScript addresses this with BigInt, but JSON.parse() still does not handle large integers as BigInt automatically — workarounds include using a custom reviver or a third-party library like json-bigint.

JSON Schema (currently at draft 2020-12) extends JSON with a meta-layer for validating document structure. A JSON Schema document specifies type constraints, required fields, numeric ranges, string patterns, and allowed enum values using JSON itself as the schema language. OpenAPI/Swagger uses JSON Schema to define the shape of API request and response bodies. The most widely used JavaScript validator is ajv (Another JSON Validator), which powers tools ranging from webpack to ESLint. Within a schema, $ref enables reuse of common definitions, while oneOf, anyOf, and allOf model union and intersection types. JSON Schema validation is runtime validation — it catches data shape errors in production payloads. TypeScript type checking is compile-time validation — it catches shape errors in source code. The two are complementary: a TypeScript type keeps your code correct; a JSON Schema keeps incoming API data correct.