ToolVault

Symptom: Chinese turned into \uXXXX

You paste a JSON containing Chinese into a formatter, and the output shows something like this:

{
  "name": "\u4e2d\u6587",
  "city": "\u5317\u4eac"
}

Instead of "北京" you see a string of \uXXXX tokens. Many people assume it is "garbled" or the tool is broken. It is not — this is a perfectly valid JSON Unicode escape, and the data is not corrupted.

Why this escape appears

The JSON string spec allows any Unicode character to be written as \uXXXX (a 4-digit hex code point). The problem is that the producer of the JSON defaulted to "ASCII-only" output:

| Language / library | Default | Escapes Chinese? | |---|---|---| | Python json.dumps() | ensure_ascii=True (default) | ✅ Escapes to \uXXXX | | Java Jackson | ESCAPE_NON_ASCII (common default) | ✅ Escapes | | JavaScript JSON.stringify() | Does not escape | ❌ Keeps Chinese | | Go encoding/json | Does not escape | ❌ Keeps Chinese |

So \u5317\u4eac is just the UTF-16 code-point representation of "北京". Same data, different display form.

How to get readable text back

Method 1: one-click with an online tool (recommended)

Open the JSON Formatter on ToolVault and paste your JSON:

1. The tool displays content in a readable form by default, so Chinese shows up as normal 北京;
2. If you need to force-keep or force-expand escapes, toggle the "escape non-ASCII" option;
3. Everything is parsed locally in your browser — no data is uploaded to any server.

Note: JSON.parse() already converts escapes back to characters automatically. The real issue is the producer defaulting to escaping; the formatter just shows the raw content faithfully.

Method 2: avoid the escape at the code level

If you generate the JSON yourself, just turn ASCII-only off:

import json
data = {"name": "中文", "city": "北京"}
# Defaults to escaping as \uXXXX
print(json.dumps(data))
# Turn escaping off to keep Chinese
print(json.dumps(data, ensure_ascii=False))

const data = { name: '中文', city: '北京' };
// JSON.stringify keeps Chinese by default, no escaping
console.log(JSON.stringify(data));

// Jackson: disable non-ASCII escaping
ObjectMapper mapper = new ObjectMapper();
mapper.configure(JsonGenerator.Feature.ESCAPE_NON_ASCII, false);
String json = mapper.writeValueAsString(data);

When you should keep the escape

Keeping \uXXXX is actually safer in some cases:

• Logs / config files that must stay ASCII-only for legacy systems;
• Cross-language transport where the receiver has weak UTF-8 support;
• Avoiding secondary mojibake from mismatched BOM / encoding declarations.

Rule of thumb: human reads it → convert to Chinese; machine needs stability → keep the escape.

FAQ

Is \uXXXX mojibake?

No. It is the standard escape form of a Unicode code point and any JSON parser restores it losslessly. Real mojibake is usually 中文 from a GBK/UTF-8 mismatch.

Why does it look fine in the browser but escapes in the tool?

The source you copied (backend API, log) was likely ASCII-only output. The tool just shows it faithfully. Use Method 1 above to display it readably.

Does converting change the data?

No. Escaped and unescaped are two text representations of the same data; the parsed string bytes are identical.

Provided by ToolVault. More JSON tools: JSON Diff, JSONPath Query, JSON Schema Validator. Visit the home page for more developer tools.