How to Write a Windows File Path in JSON

A Windows path pasted directly into JSON can either cause a syntax error or quietly become a different string. The backslash introduces an escape inside JSON text, so a path containing \n or \r can parse successfully while no longer containing the intended folder separators.

This walkthrough represents the fictional path below as a JSON string. It does not create, open or verify a file:

C:\new\report.txt

Distinguish the path value from its JSON representation

The intended path contains one backslash before new and another before report.txt. Inside a JSON string, represent each of those backslashes with a pair:

{"path":"C:\\new\\report.txt"}

The doubled characters belong to the serialized JSON text. After parsing, each pair represents one backslash in the value. They do not ask the file system to use two separators.

RFC 8259 defines the JSON string escapes, including the representation of a backslash. Use straight double quotation marks around the string; keep its original spelling and folder names intact.

Format the correctly escaped example

1. Open the JSON Formatter and Validator.
2. Paste the complete JSON object above into Paste your JSON, rather than pasting the bare path.
3. Choose 2 spaces under Indent. Leave Minify and Sort keys alphabetically unchecked.
4. Select Format JSON and inspect the output.

{
  "path": "C:\\new\\report.txt"
}

The tool displays its valid JSON message and retains the two escaped separator pairs. It uses JavaScript parsing and serialization. MDN describes JSON.parse as constructing a value from JSON text; the resulting value is different from the characters used to serialize it.

Recognize the valid JSON that represents the wrong path

Now try this deliberately incorrect representation with only one backslash at each position:

{"path":"C:\new\report.txt"}

The current formatter still accepts it. Both escape sequences are permitted JSON syntax, but their meaning is wrong for this intended path:

In the incorrect sample, the letter n becomes part of the newline escape, and r becomes part of the carriage-return escape. The parsed value contains those control characters followed by the remaining letters ew and eport.txt. It is not the intended path shown at the start.

Formatting rebuilds the control characters as readable escapes, so the mistake can remain visually similar in the output. Adding indentation cannot tell the formatter that these characters were supposed to be folder separators. Compare the represented value with the authoritative path, not just the success message.

Treat an unrecognized escape as a separate failure

This sample fails parsing because \q is not a JSON escape:

{"path":"C:\queue\report.txt"}

The tool reports an invalid JSON message. Exact browser error wording can vary. For the intended path in this example, the corrected representation is:

{"path":"C:\\queue\\report.txt"}

Do not infer that all single-backslash mistakes produce an error: the earlier \n and \r example demonstrates why that check is insufficient. Our JSON syntax repair guide covers other punctuation failures.

Serialize the actual value and check the receiving application

When an application generates this field, pass its actual path string to the language’s JSON serializer instead of assembling JSON with text concatenation. In JavaScript, JSON.stringify converts a value into JSON notation. The path must already be correct before serialization; a serializer cannot reconstruct missing backslashes from a value containing unintended control characters.

Use the appropriate representation for the destination field. A field requesting JSON text needs the escaped JSON form. A file picker or a plain path field generally expects the actual path value; follow that application’s documented input format. These examples show JSON text, not a string literal embedded in another programming language.

Avoid a blanket backslash-doubling edit on an already serialized document. Doubling the correct pairs again would represent two backslash characters at each position. After the correction, verify the parsed value against the original path and test the intended operation in the receiving application. Formatting alone cannot confirm that the file exists or that the application can access it.