JSON to String Converter

Three pages, three different jobs, and the fastest way to pick the right one is by what you already have and where it needs to go. JSON Escape produces only the escaped BODY of a string — no surrounding quotes — for when you already have delimiters of your own and just need the inside filled in safely. [JSON Stringify Online](/json-stringify-online) reproduces exactly what JavaScript's own JSON.stringify() function does (compact by default, an optional space argument, an unstringify mode) — it's the page for JS-stringify SEMANTICS specifically, in JavaScript. This page is neither: it's a complete, ready-to-paste string LITERAL — quotes included — for eight different languages, built for when the destination isn't JavaScript, or when the destination is JavaScript but you specifically want the finished literal rather than JSON.stringify()'s own compact-by-default behavior.

Pick the language the literal has to compile or run in — the eight modes exist because eight ecosystems genuinely disagree about how a string is delimited and what an embedded quote becomes inside one, and pasting the wrong mode's output produces a syntax error rather than a warning. JavaScript and Java share the double-quote-plus-backslash family (they differ only on non-ASCII handling); Python, SQL and PowerShell share single quotes but disagree on how to escape an embedded one; C# verbatim and Go raw are the two modes that keep real newlines instead of \n, at the cost of their own restriction (C# only needs "" doubled, Go can't contain a backtick at all). The quote-rules table further down lists all eight side by side.

Because that's each language's own idiomatic default when a string's content might contain a double quote (which JSON-serialized text always does, since every JSON key and string value is itself double-quoted) — Python's own repr() reaches for single quotes specifically to avoid escaping the double quotes JSON text is full of, while Java has only one string-literal syntax, always double-quoted, so its escapes go the other way instead. Neither choice is arbitrary: it's the form that needs the fewest escapes for JSON-shaped content in that language, which is also why this converter picks the same convention rather than always defaulting to one quote style.

Pick the matching mode and paste the output as-is — both are deliberately the two modes that keep real line breaks instead of converting them to \n, which is exactly what makes a multi-line JSON literal readable in the two languages that support raw/verbatim strings. The trade-off differs by language: Go's `…` raw string has no escape mechanism at all, so if your JSON's content happens to contain a literal backtick character this tool refuses the conversion outright and tells you to use the JavaScript form instead, rather than silently producing a string Go can't compile. C#'s @"…" verbatim string is more forgiving — its only special rule is that an embedded " must be written twice (""), which this mode handles automatically.

Only for the JavaScript mode's output — [String to JSON](/string-to-json) unescapes standard JSON-string backslash sequences, which is exactly what the JavaScript mode produces, but not what Python, SQL, C# verbatim or Go raw mode emit, since those use different escaping and quoting rules entirely. Key order always survives regardless of mode, since escaping never reorders anything; indentation does not, since String to JSON re-serializes at whatever indent you choose there.