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.

reference guide JSON Unicode

// what's actually there

"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.

what you see{ "name": "Alice", "role": "admin" }what's actually there{ "name": "Alice",·"role": "admin" }U+00A0 (non-breaking space) — identical on screen, invalid here
Two renderings of the exact same bytes. The top line is what your editor shows you. The bottom line is what's actually in the file — a non-breaking space where you'd swear there's just a normal one, sitting right where the parser gives up.

// 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.

space-like (normalized to a real space)
U+00A0NO-BREAK SPACE (NBSP) — by far the most common; every space you type in Word or on most web pages after a manual line-layout tweak becomes this
U+2000 – U+200AEN QUAD through HAIR SPACE — eleven typography-width spaces used by professional layout and publishing tools
U+1680OGHAM SPACE MARK
U+202FNARROW NO-BREAK SPACE — French typographic convention, appears in text authored with certain locale settings
U+205FMEDIUM MATHEMATICAL SPACE
U+3000IDEOGRAPHIC SPACE — the standard full-width space in Japanese/Chinese/Korean text input
U+FEFFZERO WIDTH NO-BREAK SPACE, a.k.a. the byte-order mark (BOM) — see below
zero-width (removed entirely)
U+200BZERO WIDTH SPACE — invisible line-break hint, common in text copied from web pages
U+200CZERO WIDTH NON-JOINER
U+200DZERO WIDTH JOINER — also what glues emoji together into combined glyphs
U+2060WORD JOINER

// 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

by source
Word / Outlookautocorrect inserts NBSP around certain punctuation and at manual line breaks; also converts straight quotes to curly ones, a separate but related failure mode
Confluence / Jirarich-text-to-plain-text copy frequently carries over NBSP from the page's own layout spacing and zero-width characters from its rich-text editor's internal formatting
Web pages generallyany page using   for layout spacing hands you a literal NBSP the moment you copy that text
Windows tools writing filesNotepad and some .NET encoding defaults prepend a BOM; harmless for most text viewers, fatal for a strict JSON parser

// 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.