JSONL Encoding Fixer
Fix the invisible problems that stop a JSONL file from parsing. Byte-order marks, Windows line endings, zero-width characters, typographic quotes pasted from a document, blank lines, trailing whitespace, a missing final newline — each fix is counted so you can see what was actually wrong.
Fix
What each fix addresses
- BOM — an invisible U+FEFF at the start of the file, added by some Windows editors and by Excel exports. Parsers reject line 1 with a message that makes no sense next to what you see.
- CRLF and lone CR — Windows and classic-Mac line endings. Many JSONL readers split on
\nonly, leaving a stray\rat the end of every line, which then fails to parse or ends up inside your last value. - Zero-width characters — U+200B–U+200D, U+2060, U+FEFF mid-file. They come from copying out of web pages and PDFs and are completely invisible, which makes ids that look identical compare as different.
- Typographic characters — curly quotes, en and em dashes, ellipsis, non-breaking space. Curly quotes are the classic cause of "my JSON looks right but will not parse" after editing in a word processor.
- Trailing whitespace and blank lines — harmless to most parsers, but blank lines break strict readers that expect exactly one object per line, and trailing spaces break naive line splitting.
- Final newline — a JSONL file should end with one. Without it, appending another record silently joins two objects on one line.
The one thing this cannot fix
If the report mentions U+FFFD replacement characters (�), the damage
happened before the file reached this page: the bytes were decoded with the wrong character encoding —
typically Latin-1 bytes read as UTF-8 or the reverse — and the original characters are gone. No amount of
post-processing recovers them.
The fix is upstream. Re-export the file as UTF-8, or if you still have the original bytes, decode them with
the correct encoding (iconv -f windows-1252 -t utf-8 is the usual incantation). This tool
counts them so you know to go back rather than trying to patch the symptom.
Structural problems are a different tool
This page fixes encoding and whitespace. If lines fail to parse because the JSON itself is broken — trailing commas, unquoted keys, single quotes, a truncated last line — use the Auto-fixer, which repairs syntax and shows what it changed. Running this tool first and the Auto-fixer second is the usual order, because invisible characters make syntax errors much harder to read.
Privacy
Nothing is uploaded. The whole thing runs in this tab, in your own browser. That matters here more than on most tool sites — training data is usually the most sensitive file a team owns.
Frequently asked questions
Is replacing smart quotes safe?
It rewrites characters inside your string values, so it changes data. For a dataset of prose that was pasted out of a document it is what you want. For anything where the exact characters matter, leave it off and fix the source.
Why remove blank lines rather than ignore them?
Most readers skip them, but strict ones do not, and a blank line in the middle of a file often means a record was deleted badly. Removing them makes the file unambiguous. Turn the option off if your pipeline uses blank lines as separators.
Does it validate the JSON?
It reports how many lines parse after cleaning, and compares against before, so you can see whether the encoding fixes solved the problem. For a full line-by-line report use the Validator.
Can it handle a 1 GB file?
The file is processed in memory as a string, so very large files depend on browser memory. For multi-gigabyte cleanup, sed and iconv in a shell are the right tools.