JSON Stringifier

What is a JSON stringifier?

A JSON stringifier serializes a JSON document back to text, collapsing it onto one line so it can be stored or transmitted anywhere a single value is expected. That is the default mode here. A second mode goes one step further: it wraps the result in quotes and escapes it, so the whole document becomes a valid string literal you can drop straight into source code or nest inside another JSON payload.

Paste JSON in and the result is ready to copy immediately, with a live character count so you can see the size of each mode. Two independent toggles control the output. "Wrap as string literal" double-encodes the result, quoting it and escaping the inner quotes and backslashes. "Escape unicode characters" rewrites every non-ASCII character as a \uXXXX sequence, and because it runs last, it applies to whichever form you chose. Leave both off and you get compact JSON, with the escapes your string values already had left unchanged. If the input is not valid JSON, the parser's error message replaces the output so you know what to fix.

When to use it

Most visits here start with a field that will only take one line. A curl body in a shell script chokes on a pretty-printed object spread across twenty lines, and so does a GitLab CI variable, a Terraform locals block, or a Kubernetes ConfigMap value. Collapsing it makes it paste-safe without changing what it means. Storage has the same problem. Audit-log columns typed as TEXT, queue message bodies, and inline test fixtures all want the compact form, which is smaller and diffs as a single change.

The wrap mode covers a narrower and more annoying case: JSON that has to survive being read as a string first. Embedding a payload in JavaScript or Python source, where the whole document sits between quotes. Nesting JSON inside another JSON document, as an API field that carries a serialized body. Handing a value to a Terraform variable declared as a string, or a workflow input that takes JSON-as-text. Paste compact JSON straight into any of those and the first inner quote closes the outer one, a syntax error on the spot. Wrapping is what stops that.

The unicode toggle earns its place when the pipeline between you and the consumer is not reliably UTF-8. An older database driver, a legacy SOAP endpoint, a CI runner with an ASCII locale, and a log pipeline that mangles bytes it does not recognise all qualify. Escaping to \uXXXX makes the payload pure ASCII, so accented names and emoji survive the trip instead of arriving as question marks. It composes with the wrap toggle, so an ASCII-only string literal is one checkbox away.

How this tool works

Your input is parsed with JSON.parse() and re-serialized with JSON.stringify(). Parsing first validates it: a throw there gives you the parser message instead of a broken result. Prose, a bare identifier, or a half-copied fragment fails there, since this tool serializes a JSON document rather than quoting arbitrary text. Re-serializing compacts the output: whitespace between tokens goes, key order stays. Escapes inside string values carry through unchanged, so a double quote that arrived as \" stays \", a backslash stays \\, an escaped line break stays \n. They were already part of your JSON. The escaping is JSON's own, which also fits JavaScript, Python, Java, Go, and anything using double-quoted strings. A destination that adds its own quoting (a YAML block scalar, a shell single-quoted string, a CSV cell) needs that layer separately. There is no indentation option, because pretty-printing is what the JSON Formatter is for.

Both toggles are extra passes over that result, in fixed order. "Wrap as string literal" runs JSON.stringify() a second time: quotes go around the whole document, every inner " becomes \", every backslash doubles, and nothing inside can end the string early. The result is a JSON string containing your document, the double-encoded shape seen in the wild and the shape the JSON Parser unwraps. "Escape unicode characters" then replaces every character above U+007F with its \uXXXX form. Running last, it covers the finished output either way. Emoji and anything else outside the Basic Multilingual Plane emit the surrogate pair JSON uses, two escapes for one character. Every combination round-trips: parse the output the right number of times and your value comes back.

Nothing you paste leaves the tab. The parse and the re-serialize both run locally, so there is no upload step and no request to find in your network panel. Local execution matters when the payload you are collapsing is production data on its way into a config file.

Examples

• Collapsing a payload for a CI variable

  Input

  {
    "event": "signup",
    "userId": 41,
    "tags": ["beta", "eu"]
  }

  Output

  {"event":"signup","userId":41,"tags":["beta","eu"]}

  The default mode. Numbers, booleans, and arrays need no escaping at all. The work here is flattening four lines to one so the value fits in a single-line env var or pipeline variable field.

• Escapes in your values are preserved, not added

  Input

  {
    "message": "Line one\nLine two",
    "quote": "She said \"yes\""
  }

  Output

  {"message":"Line one\nLine two","quote":"She said \"yes\""}

  Formatting whitespace between tokens is gone. The escapes inside the values survive untouched: \n stays a two-character escape rather than becoming a real line break, and the inner double quotes stay \" so they cannot terminate the string early.

• Wrapped as a string literal

  Input

  {
    "event": "signup",
    "userId": 41
  }

  Output

  "{\"event\":\"signup\",\"userId\":41}"

  With "Wrap as string literal" on, the whole document is quoted and every inner quote is escaped. Paste this straight after an equals sign in JavaScript source, or into a JSON field that expects a string, and it parses back to the original object with no hand-editing.

• Wrapping doubles the backslashes

  Input

  {
    "path": "C:\\Users\\dev"
  }

  Output

  "{\"path\":\"C:\\\\Users\\\\dev\"}"

  A Windows path already carries doubled backslashes in JSON. Wrapping adds a second layer, so each one doubles again. The run of backslashes looks alarming and is correct: parse the string once to get the JSON back, and the path is unchanged.

• Unicode escaping for an ASCII-only pipeline

  Input

  {
    "name": "café",
    "status": "shipped 🚚"
  }

  Output

  {"name":"caf\u00e9","status":"shipped \ud83d\ude9a"}

  Every non-ASCII character becomes \uXXXX. The truck emoji sits outside the Basic Multilingual Plane, so it emits two escapes. That surrogate pair is correct, and parsing the output returns the original emoji. Turn on wrapping as well and the escapes are preserved inside the quoted literal.

Frequently asked questions

• What does it mean to stringify JSON?

  Stringifying JSON means serializing it back to its compact text form: one line, no whitespace between tokens, every string value written using standard JSON escapes. That is the form you want when JSON has to travel as text, whether the destination is an env var, a CI variable, or a column that stores it as a string.

• How do I put JSON inside a JavaScript string?

  Turn on "Wrap as string literal" and paste the result straight between quotes. Wrapping double-encodes the document, escaping every inner quote and backslash so nothing terminates the string early. Paste compact JSON in directly and it breaks at the first inner quote, which is the error most people hit before they find this option.

• What is the difference between the two output modes?

  The default gives you JSON: valid to parse once, and the right choice for an env var, a text column, or a curl body. Wrapping gives you a JSON string containing that JSON. It needs parsing twice, and it suits a destination that reads the value as a string first: source code, a nested API field, a Terraform variable typed as string.

• What is the difference between JSON stringify and JSON parse?

  They run in opposite directions. Stringify takes JSON and produces text; parse takes text and produces a value you can inspect. This page goes structure to text. If you have a string and want to check that it is valid, or unwrap one that was encoded twice, the JSON Parser does that and handles the double-encoded case automatically.

• Should I turn on unicode escaping?

  Turn it on when the payload has to pass through something that may not handle UTF-8 cleanly. Older database drivers, legacy APIs, ASCII-locale CI runners, and byte-mangling log pipelines are the common cases. Leave it off otherwise, since \uXXXX escapes are harder to read and make the output roughly six times longer per non-ASCII character. Either way the JSON stays valid and parses back to the same value.

• Can I get a custom version of this for my team?

  Yes. If escaping and collapsing payloads by hand has become a standing step in someone's routine, it belongs in a script instead: a batch converter for a migration, or a pipeline step that compacts and checks payloads before they are written. Zinc Online Solutions builds that kind of internal tooling; tell us what the manual version looks like today.