Serializar JSON

This is the operation behind a recurring, unglamorous job: putting one payload inside another. A request body inside a webhook definition. A fixture inside a test file. A configuration document inside a Kubernetes ConfigMap value. A sample response inside an OpenAPI example field. In each case the inner document has to become a string in the outer one, which means every quote, backslash and newline inside it needs escaping.

People do this by hand with find-and-replace, and it goes wrong in a specific, predictable way. If you replace the quotes first and the backslashes second, the backslash you just introduced in front of each quote gets escaped a second time: you wanted \" and you have \\", which parses as a literal backslash followed by the end of the string. The document appears to work until something in it contains a quote.

Escaping in a single character scan makes that impossible. Each character is examined once and mapped once — " to \", \ to \\, newline to \n, tab to \t — with no opportunity for a later pass to re-process an earlier pass’s output.

RFC 8259 requires every control character below U+0020 to be escaped, so anything without a shorthand becomes a \u sequence. Non-ASCII characters are left alone by default, because modern JSON is UTF-8 and escaping them only makes the result larger and less readable. When a target genuinely needs pure ASCII — an older log pipeline, a system that mangles high bytes — the option escapes them, and correctly emits a surrogate pair for anything outside the Basic Multilingual Plane, since a single \u cannot represent an emoji and emitting one truncates it.

By default the input is validated as JSON first. Escaping something broken produces a string literal that is itself valid but whose contents will fail to parse later, somewhere much less convenient. Switch that off to escape arbitrary text, which is useful for log lines and shell snippets.