JSON Is Invalid But Looks Correct
You paste JSON copied from Jira, Confluence, or Word. The parser says Unexpected token at position 47. You look at position 47. There's nothing there — just what looks like ordinary whitespace between two fields. The JSON is not fine. Something you can't see is sitting exactly where the parser choked.
// what's actually there
// the 21 characters, by category
This is the exact set ToolSharp's JSON Formatter checks for — 17 space-like characters it normalizes to a real space, and 4 zero-width characters it removes outright, both only outside quoted strings, so actual text content in your data is never touched.
// the byte-order mark deserves its own mention
U+FEFF at the very start of a file is a special case: it's a leftover marker from UTF-8/UTF-16 auto-detection, written automatically by Windows Notepad, older versions of Excel's "CSV UTF-8" export, and plenty of .NET file-writing code paths that default to a BOM-emitting encoding. A JSON parser expects the very first character to be { or [ — a silent BOM in front of it is one of the most common "my JSON file works everywhere except this one CI pipeline" bugs, because the BOM is invisible in most editors but not in a strict parser.
// why your editor doesn't warn you
Fonts render most of these characters as ordinary blank space (that's the entire point of a space-width Unicode character) or as literally nothing (a zero-width character has no glyph to draw). Your editor isn't hiding a problem from you — there's nothing to show. The character is doing exactly what Unicode designed it to do; it's just not one of the four characters JSON's grammar recognizes as whitespace.
// where they actually come from
for layout spacing hands you a literal NBSP the moment you copy that text// frequently asked questions
Why does my JSON fail to parse when it looks completely correct?
Something invisible is sitting exactly where the parser chokes. "Blank space" isn't one character — JSON's grammar only permits four as whitespace (plain space, tab, carriage return, line feed), but word processors, browsers, and chat clients routinely insert other space-like or zero-width characters that render identically to a normal space, or don't render at all, and are byte-for-byte a completely different character.
What is the most common invisible character that breaks JSON?
U+00A0, the non-breaking space (NBSP). Every space typed in Word, or on most web pages after a manual line-layout tweak, becomes this character — and it renders identically to a normal space while being completely invalid outside a quoted string in JSON.
Why does JSON copied from Jira or Confluence fail to parse?
Rich-text-to-plain-text copy from Confluence and Jira frequently carries over NBSP from the page's own layout spacing, plus zero-width characters left behind by the rich-text editor's internal formatting. None of this is visible in a normal editor, but a strict JSON parser rejects it immediately.
What is a BOM and why does it break JSON files?
U+FEFF at the very start of a file is a byte-order mark — a leftover UTF-8/UTF-16 auto-detection marker written automatically by Windows Notepad, older Excel "CSV UTF-8" exports, and some .NET file-writing code paths. A JSON parser expects the very first character to be { or [, so a silent BOM in front of it is one of the most common "works everywhere except this one CI pipeline" bugs.
How do I find an invisible character in JSON?
Paste it into a tool that flags them explicitly — ToolSharp's JSON Formatter's "Show invisible characters" option marks every offending character as a red badge with its exact code point, since a normal editor renders these characters as blank space or nothing at all and gives no visual indication anything is wrong.
// try it yourself
Paste suspect JSON into the JSON Formatter and check "Show invisible characters" — every offending character in your actual input gets marked as a red badge you can hover over for its exact code point, instead of staying invisible. Click Auto-fix and it reports specifically what it changed, e.g. "Normalized 3 invisible spaces (U+00A0) at line 4, col 12 · Removed 1 zero-width character (U+200B)" — not just a generic "this was fixed." The "Try a broken example" button loads a sample with several of these at once if you want to see it before pasting your own. If the error you're staring at is a raw position N instead, see "Unexpected Token in JSON at Position N" for what that number actually means.
"Blank space" in a text file is not one character — it's dozens of distinct Unicode code points, and JSON's own grammar only permits four of them as whitespace: plain space (
U+0020), tab, carriage return, and line feed. Word processors, browsers, and chat clients routinely insert other space-like or width-zero characters that render identically to a normal space (or don't render at all) but are, byte-for-byte, a completely different character — one JSON's parser has never heard of and will reject the instant it appears outside a quoted string.