DEV Community: ThatToolSite

How to Fix Common JSON Syntax Errors (Incl. AI Output)

ThatToolSite — Tue, 13 Oct 2026 16:00:06 +0000

The JSON validator shows the exact line and column of the first error, explains it in plain words, and can repair the usual mistakes. Your JSON never leaves the browser.

Check your JSON

Start with the error message, then look one line up

A JSON parser reads from the top and stops at the first character that can't be right. The line and column it reports are where it stopped, which is often just after the real mistake. In this example the comma is missing at the end of line 3:

{
  "id": 1,
  "title": "Report"
  "pages": 12
}

The validator reports line 4, column 3: Missing comma between two properties, because it only knows something is wrong when it meets "pages". So when the reported line looks fine, check the end of the line before it.

The mistakes behind most invalid JSON

JSON is stricter than the JavaScript or Python it resembles. RFC 8259, the JSON standard, allows only double-quoted strings, lowercase true, false and null, and commas only between items.

Mistake	Example	Fix
Trailing comma	["a", "b",]	Delete the comma before ] or }
Single quotes	{'name': 'Ada'}	Use double quotes for keys and strings
Key without quotes	{name: "Ada"}	Quote every key
Comments	// settings	Remove them; JSON has no comments
Python values	True, None	true, null
Curly quotes	“hello”	Straight double quotes, " … "
Numbers JSON can't read	.5, 007, NaN	0.5, "007" (as text, to keep the zeros), null
Missing comma	"a": 1 "b": 2	Add a comma between items

Fixing JSON from ChatGPT, Claude or Gemini

JSON copied from an AI answer has its own typical problems, on top of the ones above. The answer wraps the JSON in a Markdown code fence and a sentence, and models trained on JavaScript slip in trailing commas:

Here is the JSON:
```json
{
  "name": "Ada",
  "tags": ["math", "code",],
}
```

A strict parser stops at the very first character, the H of “Here”. Try to fix in the validator removes the sentence and the fence and deletes the two trailing commas, leaving valid JSON:

{
  "name": "Ada",
  "tags": ["math", "code"]
}

The other common AI problem is a reply that stops mid-way because it reached its length limit. The JSON then ends inside a string or without its closing brackets.

Check what an automatic repair changed

Repairs are guesses, and most are safe: removing a comment or a trailing comma can't change your data. Two kinds need a human look. Take this cut-off reply:

{
  "items": [
    {"id": 1, "name": "Lamp"},
    {"id": 2, "name": "Cab

Try to fix closes the string and the brackets, so the result is valid, and lists both changes. But the second item now has the name "Cab", and whatever came after it is gone. Valid is not the same as complete. Ask the assistant to continue, or to send the JSON again in smaller parts.

The second kind is a missing comma or quote in the middle of a document, where the repair has to decide where one value ends and the next begins. Read the list of changes, and compare the item count with what you expected. If you need to see exactly what moved, put the original and the repaired version side by side in JSON diff once both parse.

Valid JSON that a program still rejects

Duplicate keys. The standard says names should be unique but doesn't forbid repeats. JavaScript and Python keep the last value without warning. The validator flags them.
A byte order mark. The standard says JSON sent between systems must not start with one, and Python's json.loads refuses a string that starts with one. Save the file as UTF-8 without a BOM.
Big numbers. IDs above 9,007,199,254,740,991 lose their last digits in JavaScript. Send them as strings.
Lenient parsers. Python accepts NaN and Infinity by default, so a file can work in one program and fail in another. Check against the standard, not one parser.

Once it's valid, the JSON formatter lays it out with indentation so it's easy to read and review.

Sources

RFC 8259: The JavaScript Object Notation (JSON) Data Interchange Format
Python documentation: json. NaN, duplicate keys and the BOM

Originally published on ThatToolSite.

Count Your Tokens Before You Paste: Practical LLM Token Math

ThatToolSite — Tue, 13 Oct 2026 06:10:27 +0000

You paste a long doc into ChatGPT, Claude or Gemini and one of three things happens: the answer ignores the end of it, you hit a context limit, or the API bill is bigger than you expected. All three come down to the same number: tokens.

Here's the practical version of token maths: what a token is, quick estimates you can do in your head, how to count exactly in a few lines of code, and how to work out what a prompt will cost.

What a token actually is

Models don't read characters or words. A tokenizer splits text into chunks from a fixed vocabulary, and the model sees a list of chunk IDs.

Common English words are usually one token: the, house, token.
Longer or rarer words get split: tokenization → token + ization.
Spaces and punctuation count too. A leading space is often part of the next token (world).
Numbers, code, URLs and non-Latin scripts use more tokens per character than plain English.

That last point is the one that surprises people. The same sentence in Hindi, Japanese or Arabic can take two or three times the tokens of its English version, and minified JSON or a stack trace is far denser than prose.

Rules of thumb (good enough for a quick check)

For English prose with OpenAI's current tokenizers:

1 token ≈ 4 characters
1 token ≈ ¾ of a word, so 100 words ≈ 130 tokens
A dense A4 page of text ≈ 600–800 tokens

Other providers publish their own rough ratios, and they differ a little because each model family has its own tokenizer. Treat these as estimates; for anything that matters, count.

Count exactly in code

OpenAI's tokenizers are open source. In JavaScript, js-tiktoken runs anywhere, including the browser:

import { Tiktoken } from "js-tiktoken/lite";
import o200k_base from "js-tiktoken/ranks/o200k_base";

const enc = new Tiktoken(o200k_base);
const text = "Count your tokens before you paste.";
console.log(enc.encode(text).length); // number of tokens

o200k_base is the encoding used by GPT-4o and newer OpenAI models; older ones like GPT-4 and GPT-3.5 use cl100k_base. In Python it's the tiktoken package:

import tiktoken

enc = tiktoken.get_encoding("o200k_base")
print(len(enc.encode("Count your tokens before you paste.")))

For Claude and Gemini the tokenizers aren't published, but both APIs have a token-counting endpoint (Anthropic's count_tokens for messages, Gemini's countTokens) if you need an exact number before sending a request.

What a prompt will cost

Every API price list is per million tokens, and input and output are priced separately:

cost = input_tokens  / 1,000,000 × input_price
     + output_tokens / 1,000,000 × output_price

Worked example with made-up round prices, so the maths is easy to follow: say input costs $2 per million and output $8 per million. A 3,000-token prompt with a 500-token answer costs

3,000 / 1,000,000 × $2 = $0.006
  500 / 1,000,000 × $8 = $0.004
                 total = $0.010 per request

One cent sounds like nothing until it runs 50,000 times a day. Two things people forget:

Chat history is input every time. In a long conversation, every new message resends the whole thread, so input tokens grow with each turn.
Output is usually the expensive side. Asking for "brief" answers or a fixed format often saves more than trimming the prompt.

Five ways to cut tokens without losing quality

Strip HTML and boilerplate before you paste a web page. Navigation, footers and tags are pure token waste.
Minify or trim JSON: drop fields the model doesn't need instead of sending the whole API response.
Summarise old context. Replace the first 20 messages of a long thread with a five-line summary.
Don't repeat instructions in every message; put them once in the system prompt.
Check non-English and code-heavy inputs, because they're where token counts surprise you most.

A quick way to check without writing code

If you just want to paste something and see the count, I made a free token counter that runs entirely in your browser, so nothing you paste is uploaded. It gives exact counts for OpenAI's tokenizers, clearly labelled estimates for Claude and Gemini, and a cost calculator with a dated, editable price table.

What's the biggest token surprise you've run into: a huge chat history, a non-English document, or a JSON blob that ate the whole context window?

OCR in the browser with Tesseract.js: no server, no CDN

ThatToolSite — Mon, 12 Oct 2026 16:15:50 +0000

People OCR some of the most private things they own: ID cards, payslips, contracts, medical letters. Uploading those to a random "image to text" site never felt right, so for ThatToolSite I wanted OCR that runs entirely in the browser, with no server and not even a CDN.

Tesseract.js makes that possible. Here's what it took to make it fast, private and reliable.

Self-host everything (yes, everything)

Out of the box, Tesseract.js fetches its worker script, its WebAssembly core and the language data from a CDN. That works, but it means a third party sees every visitor who uses the tool, and the tool breaks if the CDN does. We serve all of it from our own domain under /ocr:

const worker = await createWorker(lang, 1, {
  workerPath: "/ocr/worker.min.js",
  corePath: corePath(),            // SIMD or plain build, see below
  langPath: "/ocr/lang",           // tessdata_fast, gzipped
  cachePath: "tts-ocr-fast-v1",    // IndexedDB key, bump when data changes
  workerBlobURL: false,
  gzip: true,
});

Our browser test proves it: it reads an image and fails if any request goes to another origin during OCR.

Pick the right engine build for the device

Tesseract ships a SIMD build of its WebAssembly core, which is noticeably faster where the CPU and browser support it, plus a plain fallback. We detect support with a tiny WebAssembly module that uses one SIMD instruction:

const SIMD_PROBE = new Uint8Array([0, 97, 115, 109, 1, 0, 0, 0, 1, 5, 1, 96, 0, 1, 123,
  3, 2, 1, 0, 10, 10, 1, 8, 0, 65, 0, 253, 15, 253, 98, 11]);

export function hasWasmSimd(): boolean {
  try {
    return typeof WebAssembly === "object" && WebAssembly.validate(SIMD_PROBE);
  } catch {
    return false;
  }
}

export const corePath = (simd = hasWasmSimd()) =>
  `/ocr/${simd ? "tesseract-core-simd-lstm.js" : "tesseract-core-lstm.js"}`;

Keep the download small

Sizes matter when the whole engine runs on a phone:

File	Size
WebAssembly core (SIMD or plain)	about 2.9 MB
English data (tessdata_fast, gzipped)	1.97 MB
Hindi, Spanish, French, German, Portuguese	0.6 to 1.1 MB each

We use the fast language models, not the "best" ones: they're several times smaller, and for printed text the accuracy difference is small. Language data is cached in IndexedDB, so the second visit starts instantly, and a language is only downloaded when someone picks it. None of this loads until the visitor drops an image; the page itself stays light.

Help Tesseract see the text

Most bad OCR results come from the image, not the engine. Two cheap fixes made the biggest difference:

Scale to the size Tesseract likes. It reads best when letters are roughly 20 to 40 pixels tall. Small screenshots get enlarged up to 2×, and huge phone photos are shrunk so the longest side is at most 4,000 px, which also keeps it quick.

An optional clean-up pass for faint scans and dark-mode screenshots: convert to greyscale, stretch the contrast so the darkest 1% becomes black and the lightest 1% white, and flip light-on-dark images to dark-on-light. It's a few dozen lines of pixel code with no library, and it rescues a lot of "Tesseract read nothing" cases.

Don't block the page

Recognition runs in Tesseract's own Web Worker, and we reuse one worker for every image. Calls are queued, so switching language waits for the current image instead of racing it. Progress events drive a real progress bar, and the test suite checks the page stays responsive while OCR runs.

Be honest about the limits

Tesseract is excellent on printed text and weak on handwriting, and it doesn't keep table layout. The tool says that up front rather than letting people discover it after a bad result.

How we test it

The Playwright suite generates images with known text (including a dark-mode screenshot and a Spanish sentence with accents), runs them through the tool and compares the output. It also checks the worker, core and language files come from our own server.

Try it on something private: Image to text, in your browser. It's free, and the image never leaves your device.

How we convert MP4 to MP3 entirely in the browser (WebCodecs + LAME)

ThatToolSite — Sun, 11 Oct 2026 14:00:00 +0000

Most "MP4 to MP3" sites upload your video to a server, convert it there and hand back a file. For a phone video of your kid's school concert, that's a lot of trust for a two-second job. So when I built ThatToolSite, I wanted the whole conversion to happen in the browser tab, with the file never leaving the device.

It turned out to be very doable in 2026, with one catch: browsers can decode almost everything, but they can't encode MP3. Here's how the pieces fit together.

The stack

Mediabunny reads and writes containers (MP4, MOV, WebM, MKV, M4A, OGG, MP3) and drives the browser's WebCodecs API for decoding and encoding.
WebCodecs (AudioDecoder, AudioEncoder) does the actual codec work, natively and fast.
@mediabunny/mp3-encoder, an MP3 encoder based on LAME, compiled to WebAssembly and plugged into Mediabunny as a custom encoder. (MPL-2.0; LAME itself is LGPL, credited on our About page.)

Problem 1: WebCodecs has no MP3 encoder

AudioEncoder.isConfigSupported({ codec: "mp3" }) returns false in every major browser. AAC and Opus are fine; MP3 isn't there. The fix is to register LAME as an encoder that Mediabunny can use like a built-in one. We only load it when someone actually wants MP3, so it never weighs down the page:

let mp3Ready: Promise<boolean> | null = null;

export function ensureMp3Encoder(): Promise<boolean> {
  mp3Ready ??= import("@mediabunny/mp3-encoder")
    .then((m) => {
      m.registerMp3Encoder();
      return true;
    })
    .catch(() => false);
  return mp3Ready;
}

Before offering MP3 in the UI, we check it end to end:

const canMp3 = (await ensureMp3Encoder())
  && (await canEncodeAudio("mp3", { sampleRate: 44100, numberOfChannels: 2, bitrate: 128000 }));

If anything fails (an old browser, a blocked chunk), the MP3 option is simply disabled and M4A, WAV and OGG still work.

Problem 2: doing it without freezing the page

Decoding a 10-minute video and re-encoding its audio is real work, so it runs in a Web Worker. The page posts the File to the worker (that shares a reference to the file's data rather than copying it) and gets progress messages back. With Mediabunny the conversion itself is short:

const conv = await Conversion.init({
  input,                       // the video, opened from the File
  output,                      // an MP3 output writing to a Blob
  tracks: "primary",
  video: { discard: true },    // we only want the sound
  audio: { codec: "mp3", quality: bitrateQuality(192_000) }, // our helper: kbps to a Mediabunny quality
  trim,                        // optional start/end
});
conv.onProgress = (p) => postMessage({ type: "progress", p });
await conv.execute();

Cancelling is an AbortController passed into the job; the worker checks it between chunks and the UI shows "Cancelled" instead of a half-written file.

Problem 3: not making every visitor pay for it

The media engine and the MP3 encoder are hundreds of kilobytes. Shipping them with every page would hurt the people who just wanted to read about the tool. Two changes fixed that:

Load the engine on first use, not at startup. Even the "does this browser support MP3?" check imports the engine lazily, after the page is idle.
Turn off link prefetching on pages that list many tools. Next.js prefetches linked routes in the viewport, so the homepage was quietly downloading every tool's engine.

Together these took the tool page's phone Lighthouse score from 86 to 99.

How we test it

Unit tests can't tell you whether an MP3 actually plays, so the browser test suite does the real thing in Playwright:

It generates a short test video in the browser (moving shapes plus a 440 Hz tone), encoded with Mediabunny itself.
It drops the video on the tool and downloads the MP3.
It checks the file starts with an ID3 tag or an MP3 frame sync, that the decoded duration matches the video, and that the dominant pitch is still about 440 Hz.

That last check catches the bugs that matter: wrong sample rate, mangled channels, silence.

Limits worth knowing

WebCodecs support: Chrome and Edge support everything here. Safari and Firefox support depends on the version and the codec, so the tool checks what the browser can do and says so instead of failing. Some video codecs (HEVC from iPhones) can only be decoded where the operating system has a decoder.
It's still your device doing the work. A long 4K video takes longer on an old phone than on a server farm. For a privacy-first tool that's the right trade.

If you want to see it working, the tool is here: MP4 to MP3, in your browser. It's free, and nothing is uploaded.