DEV Community: devkitlab

How to Fix JSON That Won't Parse (and Clean Up the Mess That's Left)

devkitlab — Tue, 01 Sep 2026 02:01:46 +0000

A teammate drops a line into Slack: "why does this blow up?" It's a chunk they copied out of a Python service's logs, and they want it as clean JSON so they can read it. You paste it into a formatter, hit format, and it goes red. Invalid JSON.

Here's the thing that trips people up: most of the time the tool is right and the input is wrong. Not wrong as in broken beyond repair — wrong as in it was never strict JSON to begin with. It's a Python dict that got printed, or a JavaScript object someone logged, or a payload with another payload stuffed inside it as a string. All of those look like JSON at a glance and none of them parse. This post walks through the mess in the order you actually hit it: read the error, figure out why it isn't JSON, deal with the sneaky nested case, and then — once it finally parses — make it readable.

The blob we'll fix

This is our teammate's paste, near enough to something real:

{
  users: [
    {'id': 1, 'name': "Ada", 'active': True, 'meta': '{"role":"admin","seen":null}'},
    {'id': 2, 'name': "Grace", 'active': False, 'meta': None},
  ]
}

Squint and it's obviously data. But it fails on the very first token, and it has at least four separate reasons to fail buried in five lines. We'll clear them one at a time and use it as the running example the whole way down.

First, read the error — it's more helpful than it looks

Before fixing anything, read what the parser actually said. JSON.parse doesn't fail vaguely; it fails at a specific character, and the message tells you which one. The catch is that the message looks different depending on where you ran it, and that throws people off.

Take a smaller broken example — a trailing comma — so the position is easy to count:

{"name": "Ada",}

An older V8 engine (Node before 21, older Chrome) reports:

SyntaxError: Unexpected token } in JSON at position 15

Position 15 is a character offset from the start of the string, counting from zero and including every space and quote. Count to 15 and you land on the } — the parser expected another key after the comma and got the closing brace instead. That number is the whole point: it's a location, not a vague complaint, and it's usually all you need to find the stray character.

Newer V8 (Node 21+, recent Chrome) rewrote the message and, annoyingly, dropped the plain offset:

SyntaxError: Unexpected token '}', "{"name": "Ada",}" is not valid JSON

Now you get a snippet of surrounding text instead of a number. Firefox, meanwhile, has always done the friendliest thing of the three:

SyntaxError: JSON.parse: expected property name or '}' at line 1 column 16 of the JSON data

Line and column, plus what it expected. Three engines, three dialects, same underlying fact: something at one exact spot isn't allowed there. When a formatter marks the error location for you and lets you jump straight to that line and column, this is the step it saves you — you stop counting characters by hand and go look at the spot. Paste our big blob into the JSON Formatter and it stops on the first offender and points at it; click the error and it drops the cursor right there.

So the first offender in our blob is the u in users at the top. Which brings us to why.

Why it isn't JSON: five things that look right and aren't

Strict JSON is a narrow, boring format on purpose — that's what makes it portable. Most "invalid JSON" is really valid something else that borrowed the curly braces. These are the five that show up constantly, and our blob has four of them.

Keys need double quotes. {users: [...]} is a perfectly good JavaScript object literal, and it is not JSON. JSON requires "users". This is the single most common reason a copied JS object or a console.log of one won't parse — the language lets you skip the quotes, the interchange format doesn't.

Strings need double quotes, not single. 'name' and 'admin' are out. JSON only knows ". Python's print(), Ruby's inspect output, and plenty of log formatters emit single quotes, so anything copied from those trips here immediately.

Python's booleans and null aren't JSON's. Our blob has True, False, and None — those are Python literals. JSON spells them true, false, and null, lowercase. Same trap with NaN and Infinity, which some libraries emit and strict JSON flat-out forbids; there's no valid way to write "not a number" in JSON, which is worth remembering before you rely on it round-tripping.

No trailing commas. The comma after the last user — None}, then ] — is illegal in JSON even though almost every programming language now allows it. This one bites hardest because editors and linters have trained us to leave trailing commas everywhere; JSON is the one place that still rejects them.

No comments. Not in our blob, but the same family: // and /* */ are not JSON. If you're editing a tsconfig.json or a VS Code settings file with comments in it, that's JSONC, a superset — a strict parser will choke on the comments.

You can fix these by hand, and for five lines that's fine. For anything bigger it's tedious and error-prone, which is why a good formatter has a repair pass: it will try strict JSON first, then progressively looser interpretations — single quotes, Python literals, trailing commas — and tell you what it had to assume. Repair is a convenience, not a guarantee; it's for reading a log line quickly, not for blessing untrusted input. But on our blob it does the obvious thing and hands back parseable JSON.

The sneaky one: JSON inside JSON

Fix the four problems above and the blob parses — but look at Ada's meta field:

"meta": "{\"role\":\"admin\",\"seen\":null}"

That value isn't an object. It's a string that happens to contain JSON, escaped and stuffed inside the outer document. This is everywhere once you start noticing it: a database column typed as text that holds serialized JSON, a webhook that nests its real payload as a string, a JWT whose decoded body is JSON you then have to decode again, a log field that stringified an object before writing it. A plain formatter will show you that value as one long escaped string and leave you to sort it out.

There are two moves here. If the whole thing you pasted is a JSON string — the entire blob wrapped in quotes with \" everywhere, which is what you get from copying a serialized value — then you unescape it once to turn it back into a structured document. If it's a document that has stringified JSON in some of its fields, like our meta, you want to expand the nested strings in place, so "{\"role\":\"admin\"}" becomes a real nested object you can read and fold. The JSON Formatter has both, and expanding nested strings is the one people are most relieved to find — it saves the copy-this-value-into-another-tab-paste-unescape-copy-back dance that double-encoded data usually demands.

After expanding, Ada's record finally reads like data:

{
  "id": 1,
  "name": "Ada",
  "active": true,
  "meta": { "role": "admin", "seen": null }
}

Now that it parses: minify, pretty-print, or sort keys

Valid JSON is the starting line, not the finish. What you do next depends on why you needed it readable.

Pretty-print is the default — indent it, put things on their own lines, make it scannable. Two-space indentation is the common house style and what most formatters produce. This is what you want when you're reading a response or debugging a payload.

Minify is the opposite: strip every space and newline down to one line. That's the form you want when the JSON is going into something — a request body, an environment variable, a single log line, a field in another JSON document. Nobody reads minified JSON; it's for the wire, not for you.

Sort keys is the one people underuse. JSON objects have no defined key order, so two services can emit the same record with the fields in a different sequence — and the moment you try to compare two payloads, that unstable order buries the real change under noise. Recursively sorting keys before you save a fixture, or before a diff, makes the output stable, so the next comparison shows only what genuinely changed. (One caveat: sorting rewrites the order, so if the original order mattered — a hand-tuned config where fields are grouped deliberately — copy the original first.) This connects directly to the noise problem in comparing two JSON files: normalize both sides first, and the diff tells the truth.

Where to format it: terminal, editor, code, or browser

There's no single right place, and pretending there is would be dishonest. Reach for whatever's already in front of you.

Terminal. If the file's on disk, jq is hard to beat: jq . file.json pretty-prints it, jq -S . file.json pretty-prints and sorts keys, and jq -c . file.json minifies. No jq installed? python -m json.tool file.json is on almost every machine and also reports the line and column of the first syntax error, which makes it a decent validator in a pinch. The catch: jq and python both refuse anything that isn't already strict JSON, so they're no help with the single-quote-and-True mess we started with — they'll just report the error, not repair it.

Editor. VS Code and its relatives will format a JSON file with the built-in formatter (Shift+Alt+F, or format-on-save), and they'll underline syntax errors as you type. Great when the file's already open and already close to valid; less great for a stray blob you copied from somewhere and don't want to save as a file first.

Code. Inside a program, it's just JSON.stringify(value, null, 2) in JavaScript or json.dumps(obj, indent=2, sort_keys=True) in Python. This is the right tool when formatting has to happen as part of a script or a build step, not as a one-off look.

Browser. For the specific job of paste something, see it clean, pull it back out — which is most of what "format JSON" actually means day to day — a browser tool wins on friction. Nothing to install, it formats on paste, it repairs the almost-JSON cases the terminal tools reject, and it handles the nested-string mess in place. It doesn't replace jq in a pipeline. It replaces the twelve seconds of ceremony when you just need to read something.

Why big JSON freezes tabs — and why it doesn't have to

Everyone who works with JSON has killed a browser tab this way: paste a few megabytes of log export into some online formatter, and the page hangs, the fan spins, and you close it and go back to jq. It happens often enough that plenty of people have quietly written off browser formatters for anything big.

The usual cause is naive rendering. A lot of web formatters take the whole formatted document and put all of it into the page's DOM at once — every line, every bracket, every syntax-highlighted span — and then re-do a big chunk of that work on every keystroke. At a few hundred lines you don't notice. At a few hundred thousand, the browser is trying to lay out and paint more DOM nodes than any page should hold, and it stalls.

The fix is to stop rendering what nobody's looking at. The JSON Formatter is built on an editor (CodeMirror) that only renders the lines currently in the viewport — scroll, and it builds the rows you just revealed and discards the ones you left. The document can be enormous while the DOM stays small, because the DOM only ever holds the screenful you can actually see. Syntax highlighting is incremental too: an edit re-analyzes the part that changed rather than re-parsing the whole file, and the heavier structural work (like folding every branch at once) runs against a time budget and falls back gracefully rather than freezing the tab. Add fold summaries — a collapsed array shows 5 elements, a collapsed object shows 10 keys — and you can navigate a huge payload by collapsing everything and opening only the branch you care about, without ever laying out the rest.

None of that makes JSON.parse itself free; parsing a genuinely huge file still costs something up front. But the difference between "smooth" and "frozen" is almost never the parse. It's what happens to the DOM afterward, and rendering only the viewport is what keeps it smooth.

Is it safe to paste into an online formatter?

Worth pausing on, because the honest answer is "it depends what you're pasting." A lot of the JSON you'd want to format is exactly the sensitive kind — a production API response, a decoded token, an internal config, a webhook body with customer data in it. If a formatter sends that text to a server to do the work, you've just handed a third party a copy, and "it was only for a second" doesn't un-send it.

The way around it isn't to trust a privacy policy; it's to use a tool that never needs the network. When parsing, repair, formatting, folding, and file reading all run in the browser with JavaScript, the text you paste stays on your machine — nothing is uploaded, so there's nothing to leak. That's the property to look for, and it's the reason a local-first formatter is the safe default for anything you wouldn't post publicly.

Two gotchas that survive even valid JSON

Two things worth knowing, because they pass every validator and still bite.

Big integers lose precision. JavaScript numbers are 64-bit floats, and JSON.parse reads numbers into them. A 64-bit database ID or a Twitter-style snowflake can exceed what a float represents exactly, and it silently rounds:

JSON.parse('{"id": 9007199254740993}').id
// → 9007199254740992   ← not the number you had

The JSON was valid. The ID is now wrong by one, quietly, and no error fired. If you're moving large integer IDs through anything JavaScript-based, keep them as strings.

Duplicate keys. {"a": 1, "a": 2} is technically valid JSON, and the spec doesn't say what a parser should do with it. In practice most parsers keep the last one, so this reads back as {"a": 2} and the first value vanishes without complaint. It's rare, but when a generated document has a duplicated field, this is why one of them seems to disappear.

Putting it back together

Our Slack blob started as a Python dict printout with single quotes, True/None, a trailing comma, and a payload hidden inside a string. The path out was the same order every time: read the error to find where it breaks, recognize why it isn't strict JSON, expand the nested string that was hiding real data, and only then format, sort, or minify depending on what you're doing with it next.

Formatting is usually step one, not the whole job. Once it's clean, comparing two versions is a job for a structural JSON Diff; turning a sample response into typed interfaces is what JSON to TypeScript is for; and pulling one field out of a deep payload without scrolling is what a JSONPath evaluator does. Different jobs, but they all start the same way — with JSON that actually parses, and that you can finally read.

Originally published on DevKitLab, which I build and maintain.

Why Isn't My Regex Matching? Start by Understanding the Engine

devkitlab — Mon, 31 Aug 2026 10:50:55 +0000

You write a regex, stare at it for a while, and the longer you look the more certain you are that it should match. But it matches nothing — or it matches something wildly different from what you wanted. So you start piling things on: another .*, another \, one more set of parentheses around that group. Each addition nudges it further from correct.

Here's the thing most regex tutorials won't lead with: the engine is never wrong. It did exactly what you wrote, letter for letter — it's just that what you wrote isn't what you meant. Which makes "why isn't it matching?" the wrong question. The more useful one is: where is the engine right now, what did it try, and why did it stop there? Once you can think the way the engine does, every baffling result collapses into something predictable.

This article isn't a list of tips. It spends a few minutes on how the engine works, then evolves a single example all the way through — from a pattern that's wildly wrong to one that's correct, robust, and won't tank your performance. Greedy vs. lazy, the flag you forgot to turn on, the lastIndex gotcha that makes results flip-flop, anchors, the two worlds of escaping, zero-width lookahead, the three layers of Unicode, and finally the catastrophic backtracking that can peg your CPU — you'll see they're all facets of the same machine.

What the engine is actually doing

JavaScript — like PCRE, Python's re, Java, and most engines you touch day to day — is a backtracking engine. The way it works is honestly pretty simple: the engine keeps a "current position," starts at the far left of the string, and reads one character at a time moving right, trying at each position to see whether your pattern can match starting from there.

The whole game is in that word try. Every time the engine hits a quantifier like *, +, or ?, it faces a choice: eat one more character, or stop here? A greedy quantifier (the default * and +) always chooses "eat more," swallowing as much as it can — while noting down every "I could have stopped here" position on a backtracking stack. When the pattern later gets stuck somewhere down the line, the engine doesn't give up immediately; it rewinds to the most recently noted position, spits one character back out, and tries a different way forward. Only when it has exhausted every possibility at the current position does it concede, shift the current position one to the right, and start over from scratch.

This one move — eat greedily, and when you get stuck, backtrack by spitting back out — is the master key to reading regex behavior. You'll see it again and again below: greedy overshoots because it swallows first and gives back later; lazy does the opposite because it holds off until forced; lookahead doesn't consume characters because it only peeks and doesn't actually advance; catastrophic backtracking pegs the CPU because the number of "try a different way" combinations explodes exponentially. One machine, one set of rules.

Worth knowing in passing: there's a different class of engine that doesn't backtrack — like Go's regexp and Rust's regex (the one behind ripgrep). They're built on finite automata that turn matching into a single linear scan, which makes them immune to catastrophic backtracking by construction — at the cost of dropping features like backreferences that inherently need backtracking. That explains a common puzzle: the same dangerous pattern runs blazing fast under ripgrep yet can hang a Node.js process. Which class your engine is in decides which pitfalls even apply to you. This article is about JavaScript's backtracking engine.

The string we're fixing

The whole article aims at one target, and it's close to something real — two links sitting side by side:

<a href="/products/12">Boots</a> <a href="/products/34">Hat</a>

The goal is modest: pull out both href values, i.e. /products/12 and /products/34. It's simple enough that you'd expect to nail it in one shot, yet it manages to draw out every quirk of the engine above. Before touching anything, remember one thing: the first step in debugging a regex is never to change the pattern — it's to see where it currently lands. Put the pattern, the flags, and the test text together and let it highlight each matched span right on the original — that's exactly what the regex tester is for. It turns an abstract pattern into a stretch of colored text your eyes can read. In every section below, you can paste that section's pattern in and see with your own eyes which span it actually matched.

Greedy: it didn't fail to match, it backtracked too late

Here's a first version almost everyone has written:

<a href="(.*)">

You expect (.*) to capture /products/12. What it actually captures is:

/products/12">Boots</a> <a href="/products/34

From just after the first href=", it eats all the way to just before the last ">. Through the engine's lens, this is no mystery at all: .* greedily swallowed everything from here to the end of the line in one gulp, then the engine noticed the pattern still owed one ">, so it began backtracking — spitting characters back out one at a time, from the right edge leftward. By the time it had backed up to the last ">, the pattern was satisfied and declared success, so it stopped there and never gave anything more back. It didn't "want to eat that much" — it backtracked too late to hit the first place it could close.

The fix is to add a ? to the quantifier, flipping it from greedy to lazy:

<a href="(.*?)">

.*? reverses the default choice — at each step it first picks "don't eat," and only grudgingly swallows one character when the next step won't work otherwise. So it starts from empty, expands a little at a time, and stops at the first ">, leaving (.*?) capturing exactly /products/12. Paste both patterns into a regex tester in turn and you'll watch the highlight snap back — the most direct look you'll get at greedy vs. lazy.

That said, the cleanest version is neither greedy nor lazy — it's the one that never gives the engine room to backtrack in the first place:

<a href="([^"]*)">

[^"]* means "any character except a double quote." It can't reach that closing quote to begin with, so it naturally stops right before it — no eating too much and giving it back, no backtracking at all. That's not just faster; it's safer. And here's a JavaScript hard limit worth knowing early: some engines offer atomic groups (?>...) or possessive quantifiers a++ that explicitly tell the engine "once you've eaten this, never give it back," locking out backtracking at the root. JavaScript to this day has neither. So in JS, the only lever you have over backtracking is exactly this — rewrite the pattern into a shape with no ambiguity, using a negated character class to nail down the boundary instead of leaning on .*?. Hold onto this; it's the cure when we get to catastrophic backtracking.

Flags and state: the pattern is fine, it's the engine's switches and memory

Say you've moved to <a href="([^"]*)">, but it only matches the first link; the second, /products/34, refuses to show up. Nothing's wrong with the pattern — the problem is a flag: one of those switches that default to off, don't complain when you forget them, and quietly hand you half a result.

g (global) — it makes replace handle every hit, and it's the prerequisite for matchAll. It also changes what String.prototype.match() returns: without g you get the first match plus its capture groups; with g you get all the full matches. To iterate every hit and its groups reliably, matchAll is the clearest option. Your only match above was the first because g was off.
i (ignore case) — /hat/ won't match Hat; turn on i and HAT, Hat, hat are all equal.
m (multiline) — it only changes what ^ and $ mean; next section.
s (dotall) — by default . does not match a newline. If your pattern has a .* and the content spans lines, . stops at the newline; turn on s and it treats newlines as matchable too.

That's all still common knowledge. But g hides a deeper trap: a regex with g (or y) is stateful. The same RegExp object remembers a lastIndex — where the previous match ended — and picks up from there next time. Feed the same object to .test() or .exec() repeatedly and you get this seemingly impossible result:

const re = /href/g;
re.test('href');  // true —— lastIndex advances to 4
re.test('href');  // false —— starts looking from position 4, nothing there
re.test('href');  // true —— hit the end, lastIndex resets to 0, starts over

Same string, same regex, yet test flip-flops between true and false. The culprit is that silently rewritten lastIndex. Reusing a g regex isn't wrong in itself — that's exactly how you'd deliberately walk matches with exec() — but before a .test() check that doesn't need to continue from a position, reset lastIndex = 0 or build a fresh regex. Above all, don't hoist it into a module-level constant and then test it all over the place. To read every match with its groups, prefer String.prototype.matchAll(); it derives an iterator from the original and never touches that object's lastIndex. One aside: the tester above enumerates every hit in its matches list for readability, while the replace preview still honors whether you've turned on g.

Anchors and boundaries: they match a position, not a character

Anchors are a special case in the backtracking model — they're zero-width, matching the seam between characters rather than a character itself. That's where they're most counterintuitive.

^ and $ anchor to the start and end of the whole string by default, not each line. Take this multiline text:

error: disk full
error: timeout

You write ^error: hoping to match the start of each line, but by default ^ only recognizes that one position at the very start of the whole string, so only the first line hits. To make ^ and $ fire at the start and end of every line, turn on m (multiline). These two almost always come as a pair; forgetting m is the number one reason for "why does it only match the first line?"

\b (word boundary) is another commonly misread zero-width assertion. It matches the seam "between a word character and a non-word character." \bcat\b captures cat in a cat sat, but won't match the cat in category — because cat is immediately followed by e, and there's no boundary there. Plenty of people treat \b as "a space," but punctuation and the start/end of a line count as boundaries too. And there's a deeper trap: \b decides "what counts as a word character" using the ASCII definition ([A-Za-z0-9_]), even when you've turned on u. So for Chinese, or accented Latin letters, \b will disagree with your intuition — a Han character isn't a "word character" in its eyes, so the boundary lands in the wrong place.

Escaping: one dot, two worlds

In a regex, . + * ? ( ) [ ] { } ^ $ | \ all carry special meaning; to match them literally you have to escape them with \. The most common victim is the dot: you want to match the . in a version number, so you write \d+\.\d+; get lazy and write \d+.\d+, and that bare . becomes "any character," so 1X2, 1 2, 1a2 all match — far looser than you wanted, with no error, quietly matching things it shouldn't the day some dirty data comes through.

But what really drives people up the wall is the two worlds of escaping. A tester's input box takes the raw regex, where one backslash is one \; but a regex in code often lives inside a string, and the string itself also uses \ for escaping, so the same pattern is written differently in the two worlds:

// In a regex literal, one backslash is enough:
/\d+\.\d+/

// But built from a string, the backslashes double — the string eats one layer first:
new RegExp('\\d+\\.\\d+')

"It works fine in the tester and breaks the moment I put it in code" is, nine times out of ten, this layer of backslashes not lining up — the \\d you copied out of some JSON or a log field should actually be \d when pasted into the tester, and doubled back up when returned to a code string. The tester's export feature handles that difference for you, giving you the paste-ready form in the target language and sparing you the manual backslash-counting.

There's an advanced case too: when you build a regex from a variable — say, treating user input as a literal string to match — any ., (, or ? in that input gets read as a metacharacter, which at best matches wrong and at worst lets external input rewrite your matching logic. RegExp.escape() was standardized in ES2025 and safely turns a string into a literal-match fragment; modern browsers support it, but if you need to support older browsers or runtimes, check your target environment first and reach for a maintained polyfill if necessary. When you build a regex dynamically, the variable part must be escaped first — never drop an external string straight into the pattern.

Lookahead and lookbehind: they check a condition, they don't consume characters

At this point you might want something more precise: pull out the href value without the surrounding quotes. Lookahead and lookbehind exist for exactly this, and they carry a misconception almost everyone falls for.

Back to the engine model: a lookahead (?=...) makes the engine "peek forward" to check whether what follows matches some pattern — but after that peek, the current position does not move forward. It's zero-width: whether the condition holds affects success or failure, but the characters it checks don't count toward the match result. So:

\d+(?=px)

For 12px, it matches 12, not including px. If you print match[0] and find no px in it, that's not a bug — that's the definition of lookahead. Likewise negative lookahead (?!...), lookbehind (?<=...), and negative lookbehind (?<!...) are all zero-width — they frame the context without consuming it.

This "doesn't take up characters" property is exactly what makes them valuable. To pull out the value between the quotes without the quotes, you can write:

(?<=href=")[^"]*(?=")

The lookbehind asserts "I'm preceded by href="," the lookahead asserts "I'm followed by "," and the [^"]* in the middle is the only part actually consumed and returned — the quotes are conditions only, not results, sparing you a later slice on both ends. Paste it into the tester and you'll see it vividly: the condition regions aren't highlighted, only the actually-consumed span is colored — the abstract word "zero-width" made concrete at a glance. (One JavaScript bonus: its lookbehind supports variable-length patterns, unlike some engines that allow only fixed-length lookbehind, so (?<=\w+=") is valid in JS.)

The three layers of Unicode: ASCII, code points, grapheme clusters

The moment your text contains Chinese, emoji, or any non-ASCII character, a whole layer of pitfalls is waiting — and it's deeper than most people assume. "Unicode support" actually comes in three layers, and every one of them can bite you.

Layer one: stop assuming \d and \w know about non-ASCII. In JavaScript, \d matches only ASCII 0-9 by default and \w recognizes only [A-Za-z0-9_], so \w+ can't capture a single Han character. To match by Unicode category, turn on the u flag and switch to \p{...} property escapes: \p{L} is a letter in any language, \p{N} is a number, \p{Han} is Han characters specifically, and /\p{L}+/u can finally match a Chinese word. Here's the deeply counterintuitive detail: turning on u won't make \d, \w, or \b understand Unicode — they stay ASCII-semantic. To match "any digit," including full-width and Arabic-Indic ones, you have to write \p{Nd}, not hope that u upgrades \d.

Layer two: u makes the engine walk by code point rather than UTF-16 code unit. Without u, a character that occupies two code units (like many emoji) gets sliced in half by ., and what you cut out is garbage. With u, . handles complete code points, and a notation like \u{1F600} is finally recognized.

Layer three, the one most often overlooked: a code point still isn't "one character." What the eye sees as a single character is technically a grapheme cluster, which can be assembled from several code points — a skin-toned emoji, a flag, a family emoji like 👨‍👩‍👧 glued together with zero-width joiners, are all combinations of multiple code points. Even with u on, . matches only one of those code points, so you can still shred an emoji. To handle things as "characters the way people see them," there are two roads: ES2024's v flag (unicodeSets) brings set operations and string properties like \p{RGI_Emoji} that can match a composite emoji as a whole; and for general grapheme segmentation, use Intl.Segmenter — it's not a regex, but it's the better fit for splitting text along human perception. That tester currently offers u and not a v toggle; if you need v, verify it in your target environment. When you work with emoji or multilingual text, decide up front which layer you want — it saves you a whole class of "matched half a character" problems.

It matches correctly, yet freezes the page: catastrophic backtracking

The last kind of "wrong" isn't a wrong match — it's the match hanging the moment it runs: the tab goes unresponsive, the CPU pegs. This is catastrophic backtracking, and it's the mechanism behind ReDoS denial-of-service attacks. With the engine model from earlier, you can now understand it from first principles.

The classic form is nested quantifiers:

(a+)+$

Run it against a string of aaaaaaaaaaX (whose ending is deliberately not what it wants). The inner a+ and outer + can match the same batch of characters, so that run of a's has an exponential number of ways to be split into groups: (a)(a)(a)…, (aa)(a)…, (a)(aa)…, and so on — and that trailing $ can never hold before X, forcing the engine to backtrack through every single split before it dares declare failure. Make the input a little longer and the time it takes to fail climbs steeply; exactly how long depends on the browser, hardware, and engine implementation, so you can't pin it to a fixed character count. The culprit's profile is fixed: one quantifier wrapped around another, where both can match the same batch of characters — (a+)+, (.*)*, (\d+)* are all in this family; (.*?)*, nesting lazy inside greedy, is just as dangerous.

This is exactly the payoff of that earlier setup: why, back at greedy, I urged you to use [^"]* rather than .*?. A negated character class draws the boundary up front, with no need to probe back and forth across every position. JavaScript currently has no atomic groups or possessive quantifiers — the two syntaxes that directly cap backtracking — so the go-to move is to rewrite the pattern to remove the ambiguity: keep each branch's match range from overlapping, add anchors at the right spots, swap the boundless .* for an explicit character class. The regex tester checks for potential ReDoS risk asynchronously; when it detects risk it shows an attack sample, and when it can't complete the judgment it says so clearly. It's good for catching problems early, but it's no substitute for a performance test at real input scale.

A checklist you can actually follow

Next time a regex misbehaves, don't rush to pile on characters. Go back to the engine's point of view and run this order — it locates the problem almost every time:

First see where it currently matches. Paste the pattern and text into the regex tester and look at the highlight; don't guess. Eight times out of ten the problem shows itself right here.
Overshooting? A greedy .* backtracks too late — change it to .*?, or better, the negated character class [^…]*.
Only matching the first one / first line? You probably forgot to turn on g or m.
Same code, works then doesn't? Check whether you're reusing a g regex and lastIndex is at play.
. ( [ not matching literally? Escape what needs escaping with \, and make sure the backslashes weren't eaten or doubled at the string layer.
Result has more or less than you expected? Consider whether you've treated a zero-width lookahead/lookbehind as an ordinary group.
Chinese or emoji not matching, or getting shredded? Separate the three layers — ASCII, code point, grapheme cluster: turn on u, use \p{...}, and reach for the v flag or Intl.Segmenter when needed.
Hangs the moment it runs? Look for nested quantifiers — that's catastrophic backtracking, solved in JS by rewriting the pattern.

Getting the regex right is often where the work begins. Batch-replacing what you matched into some other shape is what the text replacer does with regex capture groups; confirming exactly what changed between two versions of text is a job for the text comparison tool. But every step starts from the same place — a regex whose matches, and the reason for each step it takes, you can see clearly — not one you can only stare at and guess about.

Originally published on DevKitLab, which I build and maintain.

Where Should I Store a JWT? localStorage, Cookies, and the XSS/CSRF Trade-off

devkitlab — Fri, 28 Aug 2026 05:15:55 +0000

The first two articles in this series were about the server: how to read a token, and how to verify one without being fooled. This one moves to the browser. Once your single-page app receives a JWT, it has to keep it somewhere, and the question of where turns out to be one of the most argued-about topics in web auth — usually for the wrong reason.

It's argued as if the answer were a ranking, with one storage location that is simply "more secure" than the others. It isn't. Every option is defined by how it answers two independent questions: can JavaScript running on your page read the token, and does the browser attach it to requests automatically. The first question is about cross-site scripting (XSS); the second is about cross-site request forgery (CSRF). Each storage choice answers them differently, which means the right answer depends on which attack you're more exposed to — and, above everything else, on whether you can keep XSS out of your page at all. That last point is the one most of these debates bury, so we'll build up to it deliberately.

Two different attackers

Before comparing storage, it's worth separating the two threats cleanly, because they get conflated constantly.

XSS is when an attacker gets their JavaScript running inside your origin — through an unescaped piece of user input, a compromised third-party script, or a vulnerable dependency. Once that happens, their code runs with exactly the privileges your own code has. It can read anything your scripts can read and call any endpoint your app can call. XSS is code execution in your page.

CSRF is different and, in a way, more limited: the attacker's own site causes the victim's browser to fire an authenticated request at your API. It works because the browser automatically attaches ambient credentials — most often cookies — to requests for your domain, even when the request originates from evil.example. The attacker never sees the token and never sees the response; they simply cause an action to happen using credentials the browser volunteers on their behalf.

Keep that distinction in hand: XSS reads and acts from inside your page; CSRF forges a request from outside it and relies on the browser bringing the credentials along. The storage options line up almost entirely along these two axes.

The options, and what each one exposes

localStorage and sessionStorage. This is the default choice in most SPA tutorials, and it has one genuine strength and one fatal weakness. It is readable by any JavaScript on the page, so a single line — localStorage.getItem('token') — hands the token to an XSS payload, which can then ship it off to an attacker's server to be replayed anywhere, anytime, until it expires. That is the fatal weakness. The genuine strength is the mirror image: because the value is only ever attached to requests by your own code (as an Authorization: Bearer header), the browser never sends it automatically, so a cross-site request can't carry it. localStorage is, in other words, CSRF-immune and XSS-fatal. (sessionStorage differs only in lifetime — per-tab, cleared when the tab closes — not in its security profile.)

A regular, non-httpOnly cookie used to hold the token. As a place to keep the credential this is the worst of both worlds: JavaScript can read it and the browser sends it automatically, so you inherit the XSS exposure of localStorage and the CSRF exposure of cookies at once. (Non-httpOnly cookies are perfectly reasonable for other jobs — a language preference, non-sensitive UI state, a double-submit CSRF token — just not for holding the token itself.)

An httpOnly cookie. The httpOnly flag makes a cookie invisible to JavaScript, so document.cookie can't see it and an XSS payload can't read the token out to exfiltrate it. That is a real and valuable property. In exchange, the browser sends the cookie automatically on requests to its domain — subject to its Domain, Path, Secure, and SameSite scoping — which puts you squarely in CSRF territory and obliges you to add CSRF defenses (more on those below). But there's a subtlety here that a lot of advice gets wrong, and it deserves its own paragraph.

`httpOnly` stops theft, not abuse

The httpOnly flag prevents an XSS payload from reading the token. It does not prevent that same payload from using it. An attacker running JavaScript in your page can simply make authenticated requests from the page itself — call your "change email" endpoint, mint an API key, transfer whatever your app can transfer — and the browser will attach the httpOnly cookie to each of those requests exactly as it would for legitimate code. The attacker can't steal the token to replay it later or from another machine, but they can act as the user, right now, for as long as the page is open.

So httpOnly genuinely helps: it bounds the blast radius by stopping exfiltration, which means no long-lived stolen credential and no replay from the attacker's own infrastructure. But it does not neutralize XSS. This is the crucial correction to the common belief that "httpOnly cookies make you XSS-safe." They make you harder to rob, not immune to being impersonated while compromised.

In-memory storage — a plain JavaScript variable or a module-level closure — rounds out the set. Because nothing is written to disk, there's no persistent copy to steal; when the tab reloads or closes, the token is gone. It isn't auto-attached, so it's CSRF-immune like localStorage, and it's narrower than localStorage against theft in one respect: there's no stored copy to exfiltrate and replay later. That's a real but limited benefit — a closure variable may not even be directly reachable by injected code, yet an XSS in your origin can still call authenticated endpoints, hook into your request path, or capture a fresh token during the refresh flow. In-memory storage frustrates offline replay; it does not stop same-origin XSS from abusing the session. The cost is UX: the token vanishes on every refresh, so you need a way to silently obtain a fresh one — which is precisely the refresh-token machinery of the next article.

The truth the debate buries: XSS beats storage

Line those up and a pattern emerges that reframes the whole question. If an attacker can run JavaScript in your origin, no client-side storage location fully protects the token. In localStorage it's stolen outright. In an httpOnly cookie it can't be read, but the attacker rides it to act as the user anyway. In memory there may be no directly readable copy, but XSS can still ride the session — calling authenticated endpoints, or capturing a token as it's refreshed. There is no arrangement of browser storage that is safe against an attacker already executing code on your page.

That leads to the honest hierarchy of controls, and it's the opposite of how the question usually gets asked. Preventing XSS is the primary defense; the storage choice only decides how much worse a successful XSS gets. Anyone who tells you "put the token in X and XSS can't hurt you" is overselling — storage is damage-limitation, not prevention. So the work that actually protects your users lives mostly outside the storage decision: rely on your framework's automatic output escaping (React, Vue, and Angular all escape by default) and treat every dangerouslySetInnerHTML or v-html on untrusted data as a liability; ship a strict Content-Security-Policy, which both limits what injected script can do and restricts where it could exfiltrate a stolen token; consider Trusted Types to choke off DOM-based sinks; pin the third-party static assets you can version and hash with Subresource Integrity (it verifies a known file, so it's a spot control, not a general supply-chain fix); and keep dependencies patched, since a single compromised package in your build is an XSS with your app's full privileges. Storage choice is a real decision, but it's the second one, not the first.

If you use cookies, deal with CSRF properly

Choosing an httpOnly cookie means taking on CSRF, so it's worth knowing what actually defends against it rather than reaching for folklore.

The SameSite cookie attribute is the modern front line. SameSite=Lax, now the default in current browsers, keeps the cookie off cross-site subresource requests, and off unsafe top-level navigations — a cross-site form POST that navigates to your app won't carry it — while still sending it on ordinary top-level GET navigations, so normal links and logins keep working. It's a strong mitigation rather than an unconditional barrier: browsers ship compatibility carve-outs (notably a short "Lax-allowing-unsafe" window in which a freshly-set cookie is still sent on a top-level cross-site POST), so treat it as raising the bar, not sealing the door. Strict is tighter, but because it withholds the cookie even when a user arrives through a cross-site link, your app simply looks logged-out on that first navigation until a same-site request re-sends it. None doesn't so much re-open CSRF as remove the SameSite layer entirely — it now requires Secure, and you're back to relying on server-side CSRF defenses.

SameSite is necessary but not a complete answer. It offers no protection against a same-site attacker — a compromised or attacker-controlled subdomain is same-site to your cookie — it has historical edge cases, and older clients don't honor it. So defense in depth still applies: a synchronizer or double-submit CSRF token, validating the Origin/Referer header on state-changing requests, or requiring a custom header that a cross-site form is unable to set (browsers won't let a simple cross-origin form add arbitrary headers). Worth naming for contrast: the localStorage-plus-Authorization: Bearer approach is inherently CSRF-immune precisely because the browser never attaches that header on its own. That immunity is the one real security advantage of the localStorage pattern — paid for, as we've seen, with its XSS exposure.

Two common patterns

Two patterns have emerged as the pragmatic answers, and they're worth understanding as a pair.

The first is a short-lived access token in memory, paired with an httpOnly, Secure, SameSite refresh cookie. The access token lives in a JavaScript variable — not persisted, so nothing survives a reload to be stolen later — and it's sent as a Bearer header, so it's CSRF-immune. Crucially, it's short-lived. The refresh token, the long-lived credential you actually need to protect, lives in an httpOnly cookie scoped to the refresh endpoint, where JavaScript can't read it. On load, and whenever the access token expires, the app calls the refresh endpoint to get a new one. This deliberately puts the long-lived credential where JavaScript can't read it and keeps the reachable credential short-lived, so what an attacker can quietly exfiltrate and replay offline is only ever a token with minutes left on it. Be clear about what that does and doesn't buy, though: an XSS running in your origin can still call the refresh endpoint itself, read the new access token out of the response, and keep the session alive — and it can call your business APIs directly as the user in the meantime. Short lifetimes shrink the value of a single stolen token replayed elsewhere; they do not shrink a live same-origin XSS down to a few minutes. The pattern's real win is keeping the refresh token out of JavaScript's reach, not making XSS harmless. It leans entirely on the lifecycle machinery — short lifetimes and rotating refresh tokens — that the final article covers.

The second — stronger specifically against bearer-token exfiltration and offline replay — is the Backend-for-Frontend (BFF) pattern, in which the browser never holds the JWT at all. The SPA talks only to its own backend, authenticated by an ordinary httpOnly session cookie; that backend holds the tokens and calls the downstream APIs on the user's behalf. This is what the current OAuth guidance for browser-based apps recommends for higher-security systems, for exactly the reason this article has been building toward: it removes the bearer token from JavaScript's reach entirely, so there's nothing in the page to exfiltrate or replay elsewhere. It still isn't an XSS cure — an attacker running in your origin can drive authenticated actions through the BFF using the same httpOnly session cookie the browser attaches for legitimate code. What BFF eliminates is token theft and offline replay, not same-origin abuse. The cost is architectural — you need that backend component, and it reintroduces some server-side session state (and its own CSRF handling for that cookie) — but it sidesteps the storage debate rather than trying to win it.

A reminder from the first article, and the tool to make it concrete

It's easy to think of localStorage as a hiding place. It isn't. A signed JWT — a JWS, the kind this series and the inspector deal with — has a Base64URL-encoded payload that is readable, not encrypted, as the first article laid out. (An encrypted JWE is the exception, and a rare one in browser auth.) So the token sitting in localStorage is a plainly readable string that decodes to plainly readable claims. Paste one into the JWT inspector and you're looking at exactly what an XSS payload sees the instant it reads localStorage: the whole token, and every claim inside it, in the clear. (If you want to pull apart a single segment by hand, the Base64 encoder/decoder shows the same thing at a lower level.) That's also the reason you never put anything sensitive in the payload — storage doesn't conceal it and neither does the token.

Three myths worth retiring

"localStorage is fine as long as I sanitize my inputs." Sanitization reduces XSS; it rarely eliminates it, and it only takes one missed sink or one compromised dependency. Betting the entire, replayable token on your app having zero XSS forever is a bet worth not making — which is the whole argument for keeping the long-lived credential out of JavaScript's reach.

"httpOnly cookies make me XSS-safe." They stop the token from being read and exfiltrated. They don't stop an XSS from making authenticated requests from within your page while the user is logged in. httpOnly limits damage; it doesn't prevent it.

"Just put the JWT in a cookie." If you're going to use a stateful httpOnly cookie anyway, it's worth asking whether you need a JWT at all. A self-contained token earns its keep when verification must be stateless and distributed across services; for a single first-party web app talking to its own backend, a plain opaque session cookie backed by server-side session state is often simpler and — as the next article will make vivid — far easier to revoke. Choosing a JWT should be a decision about your verification architecture, not a reflex.

Two quick notes on scope. This debate is specific to browsers: native mobile apps should use the platform's secure storage (iOS Keychain, Android Keystore) rather than anything resembling localStorage, and desktop or Electron apps carry their own caveats. And nothing here replaces transport security — all of it assumes HTTPS everywhere, without which the storage question is moot.

Where this leaves you

The arrangement that keeps coming out on top — a short-lived access token paired with a well-guarded refresh token, or a BFF that keeps the token off the browser entirely — reduces how easily a token is stolen. But "reduces" is the honest word: given a real XSS, some exposure remains, and tokens leak through other channels too. Storage decides how easily a token is stolen; it can't decide how much a stolen one is worth once it's out. That second question — keeping the useful life of any single token short, rotating credentials so theft becomes detectable, and being able to shut a compromised session down — is the token lifecycle, and it's the subject of the final article: short lifetimes, refresh-token rotation, and revocation.

Originally published on DevKitLab, which I build and maintain.

Building a Local-First Toolbox for Everyday Digital Work

devkitlab — Wed, 10 Jun 2026 09:03:05 +0000

I’ve been working on a small tools website called DevKitLab.

It’s not a complicated idea. Most of the tools are things people already know: JSON formatting, JSON diff, regex testing, cron expressions, QR code generation, even Morse code.

None of these sound new.

But that’s kind of the point.

A lot of online tools are “good enough” only when the input is perfect. They work for clean examples, small snippets, and simple cases. But in real work, the data is usually not that clean.

It may come from logs.
It may come from an API response.
It may be copied from someone else’s system.
It may be too large for a basic textarea.
It may be valid, but still hard to read.

So I didn’t want DevKitLab to be just another long list of small utilities.

I wanted to take some common tools and make them feel a little more considered.

JSON Formatter: not just pretty-printing

JSON Formatter is one of the tools I cared about the most.

I use JSON formatters all the time, but most of them feel the same: paste JSON, click format, get indented output.

That works when the input is already valid and small.

But that’s not always what happens.

Sometimes the JSON is copied from logs and has extra characters around it.

Sometimes it has a trailing comma or a missing quote.

Sometimes a value is actually an escaped JSON string, so the structure is hidden inside another string.

Sometimes the file is a few MB, and the page starts to feel slow.

For this tool, I didn’t want to build only a textarea with a format button.

I wanted it to feel more like a lightweight JSON editor.

It can try to repair common JSON issues.
It can expand escaped JSON values so you don’t have to copy them into another tool.
It supports folding and expanding nodes, so large JSON is easier to browse.
It is designed to stay usable with JSON that is a few MB in size.

The experience is closer to working in VS Code than using a basic online formatter.

This tool shaped a lot of how I think about the rest of the site.

A small tool should not only work for demo input. It should help with the messy cases people actually run into.

JSON Diff: comparing structure, not just text

JSON Diff is another tool I wanted to make more useful than a plain text comparison.

When I compare JSON, I’m usually not interested in whitespace or formatting changes. I want to know what actually changed in the data.

Did a field get added?
Was something removed?
Did a value change?

Is the difference real, or is it just formatting?

This happens a lot when comparing API responses, config files, test results, or data from two environments.

A normal text diff can be noisy for JSON. If the formatting changes, it may look like everything changed, even when the data is mostly the same.

So the goal of JSON Diff is to make the meaningful changes easier to see.

For me, this kind of tool is useful when it reduces the amount of guessing. I don’t want to stare at two large blocks of text and mentally filter out the noise.

Regex Tester: make debugging feel less like guessing

Regex is powerful, but it’s also very easy to get wrong.

Most regex testers can show whether a pattern matches the text. That is useful, but it is not always enough.

When I debug a regex, I usually want to understand the pattern piece by piece. If I hover over a part of the expression, I want to see what it means. If something matches, I want to know why. If something does not match, I want to find the exact part that needs to change.

So I wanted this tool to feel more like a small regex workspace, not just a match checker.

The flow I had in mind was:

Write a pattern.
Hover over parts of the regex to understand what they do.
Test it against real text.
See highlighted matches and match details.
Try replace when the goal is transformation, not just matching.
Try split when the pattern is used as a separator.
Use explain to make the expression easier to read.
Export the pattern as code when it is ready to use.

DevKitLab Regex Tester showing a regular expression tested against sample text with highlighted matches

The point is not to make regex simple. Regex probably won’t ever feel simple.

But the tool should make the feedback clearer. It should help you move from “I think this pattern works” to “I understand why this pattern works, and I can use it in code.”

Cron Expression: turning a short string into real times

Cron expressions are small, but they are not very readable.

Something like 0 9 * * 1-5 is fine if you write cron all the time. But once the expression becomes a little more complex, I often want to double-check it.

Will it run when I think it will run?
What are the next few execution times?
Did I misunderstand the day-of-week field?
Is there any timezone-related confusion?

That’s what I want from a cron tool.

Not just validation, but a quick way to turn the expression into something human-readable.

This is one of those tools that feels small, but can save you from a very annoying mistake.

QR Code Generator: simple, but still worth polishing

A QR code generator sounds almost too simple.

You enter some text, and it generates a QR code.

But even simple tools can be made smoother.

Sometimes the input is a URL.
Sometimes it is plain text.
Sometimes you want to adjust the size.
Sometimes you want a quick download.
Sometimes you just want the page to stay out of your way.

For this kind of tool, I don’t think the goal is to add a huge number of features. The goal is to make the common flow fast and predictable.

Open it.
Generate the QR code.
Download or copy it.
Move on.

Morse Code: not every tool has to be serious

Morse Code is a little different from the others.

It is not something most people use every day. It is not like JSON, regex, or cron.

But I still wanted to include it because a toolbox does not have to be only about serious work.

Some tools are for debugging.
Some are for productivity.
Some are just fun to have.

Morse code sits somewhere in that last category.

It may not be the most practical tool on the site, but I like having a few tools that make the project feel less rigid.

What I’m trying to build

The more I work on DevKitLab, the less I care about simply adding more tools.

More tools are useful, of course. But quantity alone is not very interesting.

What matters more to me is whether each tool feels like someone actually thought about how it would be used.

JSON Formatter should be more than pretty-printing.

JSON Diff should make real data changes easier to see.

Regex Tester should make debugging clearer.

Cron Expression should turn abstract syntax into actual times.

QR Code Generator should keep the common flow quick.

Morse Code can just be simple and enjoyable.

None of these tools are huge products by themselves.

But if each one removes a little friction, the whole toolbox becomes more useful.

Why local-first matters to me

Another thing I care about is keeping things local whenever possible.

If you only need to format JSON, that should not require uploading it.

If you are testing regex, the text can stay in the browser.

If you are generating a QR code, the browser can do that.

If a tool can run locally, I’d rather keep it local.

Not every tool can work that way, and that’s fine.

But for many everyday utilities, the browser is already enough.

And in practice, the data people paste into tools is not always meaningless. It can come from work, APIs, configs, logs, files, or private notes. Even when it is not extremely sensitive, people should not have to send it somewhere if there is no reason to.

So local-first is not just a technical preference for me. It is part of the product experience.

What’s next

DevKitLab is still early.

Some tools are close to the direction I want. Some are still too basic and need more work.

I want to improve the examples, make the local-processing behavior clearer, polish the interactions, and connect related tools in a more natural way.

I don’t want it to become a random collection of utilities.

I want it to become the kind of site you open when you have a small digital task and just want to get it done without friction.

A JSON response to inspect.
Two JSON objects to compare.
A regex to debug.
A cron expression to verify.
A QR code to generate.
A Morse message to play with.

Small things, but they come up all the time.

Project: DevKitLab

If you use small online tools often, I’d love to know:

What’s a tool you use regularly, but still feel could be much better?

DEV Community: devkitlab

How to Fix JSON That Won't Parse (and Clean Up the Mess That's Left)

The blob we'll fix

First, read the error — it's more helpful than it looks

Why it isn't JSON: five things that look right and aren't

The sneaky one: JSON inside JSON

Now that it parses: minify, pretty-print, or sort keys

Where to format it: terminal, editor, code, or browser

Why big JSON freezes tabs — and why it doesn't have to

Is it safe to paste into an online formatter?

Two gotchas that survive even valid JSON

Putting it back together

Why Isn't My Regex Matching? Start by Understanding the Engine

What the engine is actually doing

The string we're fixing

Greedy: it didn't fail to match, it backtracked too late

Flags and state: the pattern is fine, it's the engine's switches and memory

Anchors and boundaries: they match a position, not a character

Escaping: one dot, two worlds

Lookahead and lookbehind: they check a condition, they don't consume characters

The three layers of Unicode: ASCII, code points, grapheme clusters

It matches correctly, yet freezes the page: catastrophic backtracking

A checklist you can actually follow

Where Should I Store a JWT? localStorage, Cookies, and the XSS/CSRF Trade-off

Two different attackers

The options, and what each one exposes

httpOnly stops theft, not abuse

The truth the debate buries: XSS beats storage

If you use cookies, deal with CSRF properly

Two common patterns

A reminder from the first article, and the tool to make it concrete

Three myths worth retiring

Where this leaves you

Building a Local-First Toolbox for Everyday Digital Work

JSON Formatter: not just pretty-printing

JSON Diff: comparing structure, not just text

Regex Tester: make debugging feel less like guessing

Cron Expression: turning a short string into real times

QR Code Generator: simple, but still worth polishing

Morse Code: not every tool has to be serious

What I’m trying to build

Why local-first matters to me

What’s next

`httpOnly` stops theft, not abuse