DEV Community: Vishnu Shankar

Stop counting characters to find a JSON error

Vishnu Shankar — Sun, 25 Oct 2026 15:45:03 +0000

It is late and the deploy is red. The log has one line in it: 362 characters of JSON, no line breaks, and this.

Expected ',' or ']' after array element in JSON at position 218 (line 1 column 219)

Position 218. So you find an editor that shows the column number, paste the line in, and move the cursor along until it says 219. Then you look at the characters around it and guess what is wrong.

Somewhere in that line is one missing comma. JSON.parse found it straight away. It just gave you a number instead of showing you.

Find it yourself first

Here is the line. Try to spot the mistake before you read on.

{"page":1,"per_page":3,"total":42,"data":[{"id":101,"name":"Ada Lovelace","email":"ada@example.com","roles":["admin","editor"],"active":true},{"id":102,"name":"Alan Turing","email":"alan@example.com","roles":["editor" "viewer"],"active":false},{"id":103,"name":"Grace Hopper","email":"grace@example.com","roles":["viewer"],"active":true}],"next":"/users?page=2"}

Now paste this into your browser console and see what your browser tells you:

const text =
  '{"page":1,"per_page":3,"total":42,"data":[{"id":101,"name":"Ada Lovelace","email":"ada@example.com","roles":["admin","editor"],"active":true},{"id":102,"name":"Alan Turing","email":"alan@example.com","roles":["editor" "viewer"],"active":false},{"id":103,"name":"Grace Hopper","email":"grace@example.com","roles":["viewer"],"active":true}],"next":"/users?page=2"}';
try {
  JSON.parse(text);
} catch (e) {
  console.log(e.message);
}

Chrome 145:

Expected ',' or ']' after array element in JSON at position 218 (line 1 column 219)

Firefox 146:

JSON.parse: expected ',' or ']' after array element at line 1 column 219 of the JSON data

Safari (WebKit 26):

JSON Parse error: Expected ']'

Chrome and Firefox give you a count. "Line 1" is no help when there is only one line. Safari gives you less. It says it expected a ], and nothing about where.

Make the console count

If the text is already in a variable, the console can count for you:

text.slice(200, 240);
// '"roles":["editor" "viewer"],"active":fal'

Character 218 is the quote that opens "viewer". There is no comma after "editor".

But at that hour the text is not in a variable. It is in a log, a ticket or a chat message. And the usual way to pretty-print it, JSON.stringify(JSON.parse(text), null, 2), fails with the same message. It has to parse first, and parsing is the part that is broken.

Stop counting. Format it anyway.

Broken JSON can still be formatted. Change nothing but spaces and line breaks outside strings, and the parser's line number points at something you can read.

The Express Lint validator does this when you press Validate & Format on JSON that will not parse. Same line:

The message now says line 21 column 18. Line 21 has a red bar. The quote the parser stopped on has a box round it:

      "roles":[
        "editor" "viewer"
      ],

Two values. No comma. Every other value sits on its own line, so this one is impossible to miss. One click, instead of 218 characters of counting.

Nothing else changed. The strings are exactly as you pasted them, and Ctrl+Z gives you back the one line, character for character.

When the message blames the wrong thing

Here is another line from a log. Copy it and try it yourself.

{"order":5821,"status":"shipped","items":[{"sku":"BK-101","title":"Notes on the Analytical Engine","qty":1,"price":12.5},{"sku":"BK-204","title":"Computing Machinery and Intelligence","qty":2,"price":9.99,},{"sku":"BK-310","title":"COBOL at Sixty","qty":1,"price":15}],"total":47.48}

Chrome 145:

Expected double-quoted property name in JSON at position 205 (line 1 column 206)

Firefox 146:

JSON.parse: expected double-quoted property name at line 1 column 206 of the JSON data

Safari (WebKit 26):

JSON Parse error: Property name must be a string literal

All three ask for a property name. Nothing is missing a name. The mistake is one character earlier: a comma after 9.99, with nothing after it.

Formatted, it is plain:

      "price":9.99,
    },

Line 15 ends with a comma. Line 16 closes the object. After a comma the parser expects another name, finds }, and stops there: line 16, column 5.

The one thing it will not do: guess

Formatting broken JSON has one real danger. A line break inside a string changes your data. So every quoted string is copied as written.

That needs the quotes to pair up. When they do not, nobody can say for sure where a string ends. Then the validator leaves your text exactly as it is, on one line, and only marks where the parser stopped. A wrong guess there would move text in or out of a string.

Repair, only when you ask

Repair is off unless you turn it on. After a failed check there is a Try repair button. It runs jsonrepair, an open source library, in your browser. No AI. No server.

On the first example it adds the missing comma. On the second it removes the trailing comma. Both come back as valid, formatted JSON.

When the quotes do not pair up, repair has to guess where a string ends. Read the result before you keep it.

Then see its shape

Once it parses, Open in viewer takes it to the JSON viewer in the same tab. It opens as a graph, and one click turns it into a tree. Expand all opens every level. Here is the repaired order:

The JSON stays in the tab on the way. Nothing is uploaded.

In short

Position 218 is a count, not a place. On one line it is all you get, and Safari does not even give you that. Format the text without parsing it, and the error points at a line you can read.

Try it yourself: Express Lint

btoa('café') gives you the wrong bytes, and nothing tells you

Vishnu Shankar — Sun, 06 Sep 2026 10:16:43 +0000

Run this in your browser console:

btoa('café');
// 'Y2Fm6Q=='

Now encode the same word as UTF-8 first:

btoa(String.fromCharCode(...new TextEncoder().encode('café')));
// 'Y2Fmw6k='

Same word, two different answers. Both are valid base64. Neither one throws. Only the second is what everyone else means by "café in base64".

Why this happens

btoa and atob are old. They work on "binary strings", where every character has to fit into one byte.

Anything above U+00FF has no byte to go into, so btoa throws. Anything at or below U+00FF gets used as its own byte value. That is latin-1, not UTF-8.

Take é. It is U+00E9. In latin-1 that is one byte, 0xE9. In UTF-8 it is two bytes, 0xC3 0xA9. btoa picks the latin-1 one. Everything else expects the UTF-8 one.

See it yourself

Paste this in once and you get all four cases:

const show = (text) => {
  let naive;
  try {
    naive = btoa(text);
  } catch (e) {
    naive = 'THROWS ' + e.name;
  }
  const correct = btoa(String.fromCharCode(...new TextEncoder().encode(text)));
  console.log({ text, naive, correct, back: atob(correct) });
};

['José 🎉', '日本語テキスト', 'Grüße aus München', 'café'].forEach(show);

Here is what comes back. The console prints the broken text with the control characters escaped, like \x9f, which is a hint at the real problem. More on that below.

Input	`btoa(text)`	`atob(correct base64)`
`José 🎉`	throws `InvalidCharacterError`	`JosÃ© ð\x9f\x8e\x89`
`日本語テキスト`	throws `InvalidCharacterError`	`æ\x97¥æ\x9c¬èª\x9eã\x83\x86...`
`Grüße aus München`	`R3L832UgYXVzIE38bmNoZW4=`	`GrÃ¼Ã\x9fe aus MÃ¼nchen`
`café`	`Y2Fm6Q==`	`cafÃ©`

Three things happen, not one

Encoding is loud. Anything above U+00FF throws. Emoji and CJK break straight away. That is the good case. You find out.

Decoding is quiet. Run atob on proper UTF-8 base64 and you get mojibake back, with no error at all. This is the one that hurts, and it is the common one, because the base64 usually came from somewhere else. A backend, a JWT, another tool.

Plain accented text survives. btoa('café') then atob gives you back café, exactly. é fits in one byte, so a broken tool talking to itself looks completely fine.

That last one is why this sits in code for years. Encode and decode in the same place and the test passes. So does clicking around by hand. You need two implementations before anything looks wrong, and by then the bytes are already in a database.

What the mojibake hides

The broken output has C1 control characters in it, between 0x80 and 0x9f. They do not render at all.

José 🎉 comes back as ten characters. You see seven.

So if you copy that into a bug report to show what went wrong, the invisible ones get dropped along the way, and it looks less broken than it is. It hides from the exact thing you would use to find it.

The fix

Stop handing text to btoa. Turn it into bytes yourself, and be strict on the way back.

const UTF8_ENCODE = new TextEncoder();
const UTF8_DECODE = new TextDecoder('utf-8', { fatal: true });

function encodeBase64(text) {
  const bytes = UTF8_ENCODE.encode(text);
  const CHUNK = 0x8000;
  let binary = '';
  for (let i = 0; i < bytes.length; i += CHUNK) {
    binary += String.fromCharCode.apply(null, bytes.subarray(i, i + CHUNK));
  }
  return btoa(binary);
}

function decodeBase64(b64) {
  const bytes = Uint8Array.from(atob(b64), (ch) => ch.charCodeAt(0));
  return UTF8_DECODE.decode(bytes);
}

Three things in there matter.

fatal: true. Without it, TextDecoder swaps bad bytes for U+FFFD and hands you a string anyway. That puts you back where you started: a wrong answer and no error. With it, bad input throws, so you can tell "this is not text" from "this is text and I broke it".

The chunked loop. Do not write String.fromCharCode(...bytes). Spreading a big array into arguments blows the stack. I tested it: 100,000 was fine, 125,000 threw Maximum call stack size exceeded. The limit moves between engines, so do not tune to that number. Just do not spread.

Lone surrogates. TextEncoder swaps an unpaired surrogate for U+FFFD instead of failing, so your input changes before you have encoded anything. Check first if you care:

const LONE_SURROGATE = /[\uD800-\uDBFF](?![\uDC00-\uDFFF])|(?<![\uD800-\uDBFF])[\uDC00-\uDFFF]/;

Two more things

There are two alphabets. RFC 4648 §4 uses + and /. §5 uses - and _, usually with the padding stripped. JWTs and most APIs use §5. Just accept both when you decode. You can tell them apart, and asking the user which one they have is worse than working it out.

Node does not check either. Buffer.from(b64, 'base64').toString('utf8') hands you replacement characters instead of throwing, same as a non-fatal TextDecoder. Use TextDecoder with fatal: true if the difference matters.

In short

atob and btoa are latin1-only and always have been. Encoding fails loudly, which is fine. Decoding fails quietly, which is not. And plain accented text round-trips fine through a broken tool, so nobody notices until the data goes somewhere else.

I ran into all of this building the base64 tool on Express Lint, which is why it goes through TextEncoder and comes back through a fatal TextDecoder instead of handing your text to btoa. It does both directions if you want to try any of this without writing code. Free, no account, and what you paste stays in the browser.