JSON Escape — Backslash and Forward Slash, Explained
- Backslash (\) must be escaped as \\ in any JSON string — no exceptions.
- Forward slash (/) does not need to be escaped, but many serializers escape it anyway for HTML safety.
- Both forms are valid JSON and parse identically. The choice is about readability vs embedding context.
Table of Contents
Backslash and forward slash are both subject to JSON escape conventions, but the rules are different — and people constantly confuse them. Backslash is required to be escaped; forward slash is optional. Here's the distinction that causes the most "wait, why does this library escape my URLs?" moments.
Backslash Must Be Escaped (Always)
A literal backslash in a JSON string must be written as \\. The first backslash escapes the second, and the parser sees one backslash.
Why required: a single \ in JSON is the start of an escape sequence. If the parser sees \a, it tries to interpret a as an escape and fails (JSON has no \a). To represent a literal backslash, you double it.
// Wrong — will fail to parse:
{"path": "C:\Users\Alex"}
// Correct:
{"path": "C:\\Users\\Alex"}
This trips up Windows path storage constantly. Any time you have a string with backslashes — file paths, regex patterns, escape sequences embedded in strings — you need to double each backslash when serializing to JSON.
Good news: every language's JSON serializer does this automatically. JSON.stringify, json.dumps, json_encode, json.Marshal, JsonSerializer.Serialize all handle backslash escaping. You only hit problems when building JSON by hand with string concatenation — which you should not do.
Forward Slash Escape Is Optional
JSON allows both forms — they mean the same thing:
{"url": "https://example.com/path"}
{"url": "https:\/\/example.com\/path"}
Any JSON parser accepts both. The escaped form is two characters longer per slash but semantically identical.
The JSON spec (RFC 8259) says: forward slash MAY be escaped but does not need to be. Most serializers leave it raw. PHP's json_encode is the notable exception — it escapes by default, requiring the JSON_UNESCAPED_SLASHES flag to disable.
Why Some Libraries Escape Forward Slashes Anyway
One reason: HTML-embedding safety. If your JSON is going to be rendered inside an HTML <script> tag, the substring </script> inside any string value will close the script tag and break the page.
Escaping every forward slash as \/ prevents this — the browser sees a normal character and the script tag stays open.
This was the main motivation for PHP's default behavior, back when most JSON was embedded directly in HTML. In modern stacks, the framework's HTML encoder handles script-tag safety at the rendering layer, so slash escaping in the JSON itself is redundant.
If you control both ends and the JSON is going through Content-Type: application/json APIs, turn slash escaping off. It's noise.
Reading Either Form Is Fine
On the parse side, all JSON parsers accept both escaped and unescaped forward slashes transparently. You'll never get a parse error because a slash was or wasn't escaped.
On the serialize side, check your library's defaults. A byte-level diff between JSON generated by two different languages often comes down to slash escaping — the data is the same, but the representation isn't.
If you're doing hash-based equality (e.g., content-addressable storage), normalize the JSON first with a canonicalizer rather than comparing raw bytes. JSON Canonicalization Scheme (JCS, RFC 8785) is the emerging standard for this.
Practical Recommendations
For API responses: turn off slash escaping. Clients don't care; you get slightly smaller payloads and more readable logs.
For HTML-embedded JSON: use the framework's rendering helper (e.g., @json in Blade, JSON.stringify wrapped with replace(/</g, '\\u003c') in React). Don't rely on slash escaping alone — < and & can also break script tags.
For logs and debugging: raw forward slashes are dramatically more readable. Every serializer exposes a flag to disable the escape.
For byte-exact comparisons: pick one convention project-wide (almost always: no slash escape) and enforce it with your serializer settings.
Check Your Escapes
Paste JSON — see exactly which characters are escaped and why.
Open Free JSON Escape / Unescape ToolFrequently Asked Questions
Does JSON require forward slash to be escaped?
No. The spec allows both escaped and unescaped forward slashes. Most serializers leave them raw.
Does JSON require backslash to be escaped?
Yes. A literal backslash must be written as \\. A single \ starts an escape sequence.
Why does PHP escape forward slashes by default?
Historical HTML-embedding safety. Pass JSON_UNESCAPED_SLASHES to disable.
Is \/ identical to / in JSON?
Yes. Both produce a forward slash character in the parsed string. Use whichever your serializer outputs.
