DEV Community: meng meng

Base64 Encoder / Decoder: Encode UTF-8 Text Without Corrupting Unicode

meng meng — Wed, 14 Oct 2026 01:47:58 +0000

Base64 Encoder / Decoder: Encode UTF-8 Text Without Corrupting Unicode

Last month I had to place a small JSON object inside an environment variable used by a CI job. The object contained a customer name in Chinese and a check mark. My first attempt looked fine in a local test, but the decoded value on the runner contained mojibake. The mistake was not Base64 itself; I had converted characters to bytes differently on the two sides.

Base64 is a byte-to-text encoding. It is handy when a transport accepts plain ASCII but the payload contains Unicode text or binary data. It is not compression, and it is definitely not encryption. Here are the three approaches I now use, from a repeatable script to a quick browser check.

Before encoding, I write down both sides of the boundary: “JSON text encoded as UTF-8” on the producer and “Base64 decoded to UTF-8 text” on the consumer. That sounds fussy, but it catches a real class of bugs. A JavaScript string, a UTF-8 byte sequence, and the Base64 text made from those bytes are three different values. If a database driver, shell, or HTTP form changes one stage, decoding may succeed while the final text is still wrong.

Base64 also makes data larger. Every three input bytes become four ASCII characters, plus optional padding. A 10-byte UTF-8 value therefore produces 16 Base64 characters in the example below. That overhead is acceptable for a short configuration value; it is a poor reason to embed a 40 MB video in JSON.

Method 1: encode UTF-8 safely with Node.js

I tested this example with Node.js 22.13.1. Node's Buffer API makes the byte encoding explicit, which is the detail that prevents most Unicode bugs.

Save this as base64-demo.mjs:

// Node.js 22.13.1
const input = "中文 ✓";

const utf8Bytes = Buffer.from(input, "utf8");
const encoded = utf8Bytes.toString("base64");
const decoded = Buffer.from(encoded, "base64").toString("utf8");

console.log({
  input,
  utf8Bytes: utf8Bytes.length,
  encoded,
  decoded,
  roundTripOK: decoded === input,
});

Run it with:

node base64-demo.mjs

The output is:

{
  input: '中文 ✓',
  utf8Bytes: 10,
  encoded: '5Lit5paHIOKckw==',
  decoded: '中文 ✓',
  roundTripOK: true
}

The string has four visible characters plus a space, yet it occupies 10 UTF-8 bytes. Base64 works on those 10 bytes, not on JavaScript's character count. I keep the explicit "utf8" arguments because they document the contract even though UTF-8 is Node's default here.

For files, do not read arbitrary content as UTF-8 first. Preserve the bytes:

// Node.js 22.13.1
import { readFile, writeFile } from "node:fs/promises";

const original = await readFile("input.png");
const encoded = original.toString("base64");
await writeFile("input.png.b64", encoded, "ascii");

const restored = Buffer.from(encoded, "base64");
await writeFile("restored.png", restored);

The official Node.js Buffer documentation lists the supported encodings and explains why a Buffer is the right abstraction for binary payloads.

Method 2: use Python for strict validation

When I am cleaning data rather than writing an application, Python is often faster to reach for. This version was tested with Python 3.11.1 and uses validate=True, so unexpected characters fail instead of being silently ignored.

Save it as b64.py:

# Python 3.11.1
import argparse
import base64

parser = argparse.ArgumentParser()
parser.add_argument("mode", choices=["encode", "decode"])
parser.add_argument("value")
args = parser.parse_args()

if args.mode == "encode":
    raw = args.value.encode("utf-8")
    print(base64.b64encode(raw).decode("ascii"))
else:
    raw = base64.b64decode(args.value, validate=True)
    print(raw.decode("utf-8"))

A round trip is easy to inspect:

python3 b64.py encode "中文 ✓"
# 5Lit5paHIOKckw==

python3 b64.py decode "5Lit5paHIOKckw=="
# 中文 ✓

For a binary file, replace the text conversion with Path(...).read_bytes() and write the decoded bytes with write_bytes(). That avoids an accidental text decode before Base64 even starts.

Method 3: use an online encoder for one-off values

Scripts are best when the operation belongs in a build, test, or migration. They are overkill when I only need to inspect a short API token payload or decode one value from a log.

For that case, I use a free online Base64 encoder and decoder. I can paste UTF-8 text, switch between encoding and decoding, and copy the result without installing a package. The page runs in the browser, so the text is processed client-side rather than uploaded.

I also use this browser-based Base64 tool as a second implementation during debugging. If my script and the page produce the same encoded text, I can usually stop blaming Base64 and look for a transport issue such as trimming, URL parsing, or a mismatched character encoding.

Common pitfalls I have actually hit

1. Calling `btoa()` directly on Unicode

btoa() expects a binary string whose code points fit in one byte. In Node.js 22.13.1, this fails:

btoa("中文 ✓");

InvalidCharacterError: Invalid character

In browser code, convert the text to UTF-8 bytes first or use an approach based on TextEncoder. MDN's btoa() reference includes the byte-oriented pattern. Do not “fix” this by dropping the non-ASCII characters.

2. Losing the padding

Some systems remove trailing = characters. Python's strict decoder exposes the problem immediately:

base64.b64decode("aGVsbG8", validate=True)

binascii.Error: Incorrect padding

Restore the required padding only when the producer's contract says padding may be omitted. Blindly appending = can hide a truncated value. I first check the expected Base64 variant and the payload length.

3. Mixing Base64 and Base64url

Standard Base64 uses + and /; Base64url uses - and _, often without padding. JWT sections, for example, use Base64url. Feeding one variant to a strict decoder for the other can produce an error or the wrong bytes.

In Node.js, I make the choice visible:

Buffer.from(data).toString("base64");    // standard
Buffer.from(data).toString("base64url"); // URL-safe

I never replace characters by hand unless I am implementing a documented protocol.

Quick comparison

Method	Best for	Unicode-safe step	Main trade-off
Node.js `Buffer`	Apps and CI scripts	`Buffer.from(text, "utf8")`	Requires Node.js
Python `base64`	Data cleanup and strict checks	`text.encode("utf-8")`	Text and binary paths differ
Online tool	One-off inspection	Handled in the browser	Not ideal for automation

My rule is simple: define the bytes before encoding, use the matching Base64 variant, and verify a round trip with a known value. When I need a quick independent check, the UTF-8-safe Base64 converter saves me from writing another throwaway command.

More free browser-based utilities at utilvy.com.

Case Converter: Turning snake_case API Keys Into camelCase Without Breaking Acronyms

meng meng — Tue, 13 Oct 2026 01:47:10 +0000

I inherited a Go service in March that returned JSON like this:

{
  "user_id": 8821,
  "created_at": "2026-03-04T11:20:00Z",
  "profile_image_url": "https://cdn.example.com/a.png",
  "is_2fa_enabled": true
}

Our frontend is TypeScript. Every component wanted userId, createdAt, profileImageUrl. Forty-plus endpoints, all snake_case, all needing to cross that boundary.

My first instinct was find-and-replace in the editor. That lasted about ninety seconds before I hit is_2fa_enabled.

Someone on the team suggested camelcase-keys, an npm package that does the conversion at runtime. I tried it and backed out. It walks every response object on every request, which is measurable once a list endpoint returns 500 rows, and it pushes failures into production instead of build time. I wanted the rename to happen once, in a migration script I could diff and revert.

Method 1: a Python script that walks the JSON (Python 3.11)

Renaming top-level keys is easy. The annoying part is nested objects and arrays of objects, so I wrote a recursive walker.

Before trusting it with 40 endpoints, I pinned the weird cases in a test file. Three assertions caught two bugs:

# test_recase.py — pytest 9.0.2
from recase import snake_to_camel

def test_plain():
    assert snake_to_camel("created_at") == "createdAt"

def test_acronym_stays_shouted():
    assert snake_to_camel("parse_xml_http_response") == "parseXMLHTTPResponse"

def test_leading_digit_segment():
    assert snake_to_camel("is_2fa_enabled") == "is2FAEnabled"

The middle one failed on my first attempt because xml wasn't in the allowlist yet. That is exactly the kind of bug you want to find in a test and not in a staging payload.

# recase.py — Python 3.11.1
import json
import re
import sys

# Acronyms we refuse to split apart.
KEEP_UPPER = {"2fa", "http", "xml", "api", "ip", "utc"}

def snake_to_camel(key: str) -> str:
    parts = [p for p in key.split("_") if p]
    if not parts:
        return key
    head = parts[0]
    out = head if head in KEEP_UPPER else head.lower()
    for p in parts[1:]:
        out += p.upper() if p in KEEP_UPPER else p.capitalize()
    return out

def walk(node):
    if isinstance(node, dict):
        return {snake_to_camel(k): walk(v) for k, v in node.items()}
    if isinstance(node, list):
        return [walk(v) for v in node]
    return node

if __name__ == "__main__":
    data = json.load(sys.stdin)
    json.dump(walk(data), sys.stdout, indent=2, ensure_ascii=False)
    print()

Run it against the sample above:

$ echo '{"user_id":8821,"is_2fa_enabled":true,"profile_image_url":"x"}' | python3 recase.py
{
  "userId": 8821,
  "is2FAEnabled": true,
  "profileImageUrl": "x"
}

The KEEP_UPPER set is the whole point. Without it, is_2fa_enabled collapses to is2faEnabled.

My first version listed id and url in there too. That was wrong, and the output told me so immediately: userID and profileImageURL, when the TypeScript interfaces said userId and profileImageUrl. Id and URL are acronyms in prose but ordinary Pascal segments in this codebase's naming. So the list holds only the terms that are always shouted: HTTP, XML, API, IP, UTC, 2FA.

Nested objects and arrays come along for free:

$ echo '{"user_id":1,"items":[{"order_id":9,"ship_utc_ts":"2026-01-01"}],"parse_xml_http_response":true}' | python3 recase.py
{
  "userId": 1,
  "items": [
    {
      "orderId": 9,
      "shipUTCTs": "2026-01-01"
    }
  ],
  "parseXMLHTTPResponse": true
}

Note I used p.capitalize(), not p.title(). That distinction matters, and I'll show you why in the gotchas.

Method 2: Node, for when the repo is already JS (Node 22.13.1)

If the conversion has to live in the build pipeline next to the TypeScript, doing it in Python means adding a toolchain. Node is already there.

// recase.mjs — Node 22.13.1
import { readFileSync } from "node:fs";

const KEEP_UPPER = new Set(["2fa", "http", "xml", "api", "ip", "utc"]);

const toCamel = (key) =>
  key
    .split("_")
    .filter(Boolean)
    .map((p, i) => {
      if (KEEP_UPPER.has(p)) return i === 0 ? p : p.toUpperCase();
      return i === 0 ? p.toLowerCase() : p[0].toUpperCase() + p.slice(1).toLowerCase();
    })
    .join("");

const walk = (n) =>
  Array.isArray(n)
    ? n.map(walk)
    : n && typeof n === "object"
      ? Object.fromEntries(Object.entries(n).map(([k, v]) => [toCamel(k), walk(v)]))
      : n;

const input = JSON.parse(readFileSync(0, "utf8"));
console.log(JSON.stringify(walk(input), null, 2));

$ node recase.mjs < payload.json
{
  "userId": 8821,
  "createdAt": "2026-03-04T11:20:00Z",
  "profileImageUrl": "https://cdn.example.com/a.png",
  "is2FAEnabled": true
}

One caveat worth knowing: toLowerCase() is locale-independent in JavaScript, so it's safe here. Reach for toLocaleUpperCase() instead and you invite trouble, because Turkish dotless i and German ß resolve differently per locale. MDN has the details on String.prototype.toUpperCase.

Wiring this into package.json as a prebuild step meant the renamed payload was committed to the repo, not computed on every request. Same output, zero runtime cost.

Method 3: when you just have one blob of text

The scripts above are for whole JSON documents. Most of my day isn't like that. Often I have a single column list from a database migration, or a block of constant names, and I need it flipped once and then never again.

Installing a dependency for that is silly. I open a free online case converter, paste the list, and pick the target style: camelCase, PascalCase, SCREAMING_SNAKE_CASE, kebab-case, whatever the house style needs.

Concretely, last week I had 60-odd Postgres column names from \d+ orders that needed to become a TypeScript interface. Pasting that block and hitting convert took maybe fifteen seconds. Writing a throwaway script for it would have taken longer than the migration itself.

What sold me on it: everything runs client-side. Those API payloads had real customer emails in them, and I'd rather not paste that into someone else's server. It's the same reason I don't use online JSON formatters for production dumps.

For quick one-off conversions like renaming a batch of CSS custom properties, this browser-based case tool beats typing python3 recase.py and then remembering where I saved it.

Three gotchas that cost me real time

1. str.title() mangles apostrophes. I used it in my first draft. Python's title() uppercases the letter after any non-letter, not just underscores:

>>> "don't stop".title()
"Don'T Stop"
>>> "user_id".title()
"User_Id"

Neither is what you want. capitalize() only touches the first character, which is why the final script uses it. The same behavior is documented in the Python standard types reference.

2. Uppercasing can change string length. German ß expands:

>>> len("straße")
6
>>> "straße".upper()
'STRASSE'
>>> len("straße".upper())
7

Same in JS: "straße".toUpperCase() returns "STRASSE". If you uppercase a column name and then compare lengths, or use it as a fixed-width identifier, you get silent drift. I hit this on a billing export where a customer's street field was part of a hash key.

3. Acronym round-trips are lossy. The naive regex everyone writes first:

"parseXMLHTTPResponse".replace(/([A-Z])/g, (m) => "_" + m.toLowerCase());
// => 'parse_x_m_l_h_t_t_p_response'

Going camel → snake → camel does not return you to the original:

>>> re.sub(r"(?<!^)(?=[A-Z])", "_", "parseXMLHTTPResponse").lower()
'parse_x_m_l_h_t_t_p_response'

Once XMLHTTP is exploded you cannot reconstruct it without a dictionary. That is the entire reason for the KEEP_UPPER allowlist. A short list of terms I know appear in this codebase beats any clever heuristic, because a heuristic has to guess and I don't have to.

Picking an approach

Situation	Use	Why
Whole JSON payloads, repeated runs	Python script (Method 1)	Recursive, testable, no browser
Already inside a JS/TS repo	Node script (Method 2)	No extra toolchain
One-off list of names	the case converter on utilvy.com	No install, data stays local
Anything with acronyms	Any of the above + an allowlist	Round-trips stay reversible

The rule I settled on: automate the bulk rename, keep an explicit acronym list, and never trust a converter you haven't tested on is_2fa_enabled.

More free browser-based utilities at utilvy.com

Word Counter for Writers: Counting Words, Characters and Reading Time in Python, Shell, and the Browser

meng meng — Mon, 12 Oct 2026 01:49:29 +0000

Word Counter for Writers: Counting Words, Characters and Reading Time in Python, Shell, and the Browser

Three tools, three different numbers

I shipped a newsletter draft last Tuesday at 1,097 words. Or so my editor claimed.

An hour later the editor pinged me: "this is 1,140 words, our limit is 800." I opened the same file in Google Docs and got 1,142. Neither number matched mine.

That is not a bug. It is three different definitions of the word "word" quietly disagreeing with each other.

The 800 limit was real, by the way. Their mail client truncates anything longer, so every word past the line is a word nobody ever reads. Once you know which definition your publisher uses, you stop arguing and start shipping.

Here is the sample file I use to test any counting tool. Save it as draft.txt and every number below is reproducible on your machine.

I shipped the newsletter draft last Tuesday and the editor pinged me an hour later: "this is 1,140 words, our limit is 800."

That was the third time that month. My editor counts words in Google Docs, I count them in VS Code, and the two numbers never match. Docs says 812, my status bar says 797.

The gap comes from hyphenated words and the em dash — things like "state-of-the-art" or "well — actually". Docs splits on the dash, my editor does not.

Method 1: a Python script you actually keep

wc is fine for a quick check, but it cannot tell me reading time, and it counts Markdown fences as prose. So I wrote a script I now carry between projects.

Versions used here: Python 3.11.1 (CPython, Linux x86_64).

#!/usr/bin/env python3
"""wordcount.py - count words, characters, sentences and reading time."""
import re
import sys
import unicodedata

WORD_RE = re.compile(r"[^\s\u200b]+")
SENTENCE_RE = re.compile(r"[^.!?\n]+[.!?]+", re.MULTILINE)
WPM = 200  # average adult reading speed for English prose


def normalise(text: str) -> str:
    # NFC folds "e" + U+0301 into "é", so one accented letter counts once
    return unicodedata.normalize("NFC", text)


def strip_markup(text: str) -> str:
    text = re.sub(r"```

.*?

```", "", text, flags=re.DOTALL)  # fenced code
    text = re.sub(r"`[^`\n]+`", "", text)                   # inline code
    text = re.sub(r"!?\[([^\]]*)\]\([^)]*\)", r"\1", text)  # links -> anchor
    text = re.sub(r"^#{1,6}\s*", "", text, flags=re.MULTILINE)
    return text


def count(path: str) -> dict:
    raw = open(path, encoding="utf-8").read()
    text = normalise(strip_markup(raw))
    words = [w for w in WORD_RE.findall(text) if any(c.isalnum() for c in w)]
    minutes = len(words) / WPM
    return {
        "words": len(words),
        "chars": len(text),
        "chars_no_space": len(re.sub(r"\s", "", text)),
        "sentences": len(SENTENCE_RE.findall(text)),
        "minutes": minutes,
        "read_time": f"{int(minutes)}:{int(round((minutes % 1) * 60)):02d}",
        "bytes": len(raw.encode("utf-8")),
    }


if __name__ == "__main__":
    if len(sys.argv) != 2:
        sys.exit("usage: wordcount.py FILE")
    try:
        r = count(sys.argv[1])
    except UnicodeDecodeError as exc:
        sys.exit(f"UnicodeDecodeError: {exc}\nHint: this file is not UTF-8. "
                 "Try: iconv -f latin1 -t utf-8 FILE")
    print(f"words           {r['words']}")
    print(f"characters      {r['chars']}")
    print(f"characters (no spaces)  {r['chars_no_space']}")
    print(f"sentences       {r['sentences']}")
    print(f"reading time    {r['read_time']}  ({r['minutes']:.2f} min @ {WPM} wpm)")
    print(f"utf-8 bytes     {r['bytes']}")

Run it:

python3 wordcount.py draft.txt

words           82
characters      451
characters (no spaces)  365
sentences       6
reading time    0:25  (0.41 min @ 200 wpm)
utf-8 bytes     455

The strip_markup step matters more than I expected. On a short Markdown post with one Python code block, wc -w reported 47 words while the script reported 36. Eleven phantom words, all of them def, parse, return. If you bill clients per word, that difference is invoice noise you do not want.

The normalise step is the other half. Without NFC normalisation, "e" + U+0301 reads as two characters and my character count drifts upward on any file with pasted French or Spanish text.

Method 2: one line in the shell

Sometimes I just want a number and I do not want to find the script. GNU coreutils 9.4 is on this box, and wc plus awk is enough.

awk '{n+=NF} END{printf "words: %d\nreading time: %d:%02d\n", n, n/200, (n*60/200)%60}' draft.txt

words: 84
reading time: 0:25

Pure shell if you prefer no awk:

words=$(wc -w < draft.txt)
printf 'words: %s\nreading time: %d:%02d\n' "$words" $((words/200)) $(((words*60/200)%60))

Both print 84. My Python script printed 82.

Same file, different answer. That discrepancy is the whole point of this article, and I get to it in the gotchas below.

If you live in Node instead, v22.13.1 gives you the same 82:

node -e 'const fs=require("fs");const t=fs.readFileSync("draft.txt","utf8").normalize("NFC");const w=t.split(/\s+/).filter(x=>/[A-Za-z0-9]/.test(x));console.log(`words: ${w.length}`);'

The normalize("NFC") call there is the JavaScript twin of Python's unicodedata.normalize; MDN documents it under String.prototype.normalize().

Method 3: paste it into a browser tab

The script is great until I am on a locked-down laptop, reviewing someone else's copy in a browser, with no terminal and no permission to install anything.

That is when I open a free online word counter and paste the text in. It gives me words, characters, sentences and reading time in one panel, and it updates as I type.

That is why I reach for it with work copy. Nothing gets uploaded, so I can paste a draft that is still under NDA without emailing legal first. It matters most when the text is an unreleased product announcement.

Two jobs it handles for me:

Checking a meta description against a hard limit. One I wrote last week came out at 116 characters, safely under the 155 that most search snippets show before they truncate
Sanity-checking a colleague's submitted draft without asking them to install Python

When I need the browser-based word counter to agree with my script, I paste plain text only. Feed it raw Markdown and you get the fence problem all over again.

Four things that will bite you

1. Punctuation-only tokens inflate the count. My sample has two em dashes (U+2014). wc -w counts each as a word, so it says 84. The Python filter drops any token with no alphanumeric character, so it says 82.

Neither is wrong. They answer different questions. If your publisher counts like wc, quote 84.

2. Bytes are not characters. On the same file, wc -m reports 451 and wc -c reports 455. Four extra bytes, because each em dash is three bytes in UTF-8.

I hit this the annoying way while checking a 280-character social post. I ran wc -c, saw a number above the limit, and trimmed six words that did not need trimming. The platform counted characters. Use -m, not -c.

3. A non-UTF-8 file crashes the whole thing. Files exported from older Windows tools love Latin-1. Mine did:

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xe9 in position 3: invalid continuation byte
Hint: this file is not UTF-8. Try: iconv -f latin1 -t utf-8 FILE

Convert first, then count:

iconv -f latin1 -t utf-8 latin1.txt > latin1-fixed.txt
python3 wordcount.py latin1-fixed.txt

After conversion the same file reports 3 words, 18 characters, 22 UTF-8 bytes. Before it, I got a traceback and no number at all.

4. Abbreviations break sentence counting. My SENTENCE_RE is a naive regex, not a real segmenter. Feed it "Dr. Smith arrived at 5 p.m. He left after 10 min. I stayed." and it returns 5 matches for 3 sentences:

'Dr.'
'Smith arrived at 5 p.'
'm.'
'He left after 10 min.'
'I stayed.'

I do not trust the sentence field on anything with abbreviations in it. The word and character numbers stay fine; treat sentences as a rough signal.

Which one when

Situation	Use	Gives you
Billing or hard limits, need repeatability	`wordcount.py` (Python 3.11)	Words, chars, sentences, reading time, bytes, markup stripped
Quick check in a terminal you already have	`wc -w` + `awk`	Words and reading time, one line
Locked-down machine, someone else's copy	browser word counter	All four metrics, no install, nothing uploaded
Text with accents or combined marks	Either, but normalise to NFC first	Stable character counts

One last thing I got wrong for a year: 200 wpm is a rate for English prose. Apply it to Chinese or Japanese text and the reading time is nonsense, because those scripts are not delimited by spaces and the whole word-segmentation model changes. Unicode's own rules for this live in UAX #29, which is worth a skim if you ever build a counter for CJK.

Pick one method, run it on the same sample file every time, and the 1,097-versus-1,142 argument disappears.

More free browser-based utilities at utilvy.com

How to Format and Validate JSON Without Installing Anything

meng meng — Sun, 11 Oct 2026 03:06:58 +0000

You've been there: an API returns a 400-line JSON blob, your editor won't highlight it, and the error is somewhere around line 217. Or a teammate pastes config into Slack and swears "it's valid JSON", while your parser disagrees.

Here are three ways to format and validate JSON — from terminal to browser — and when each one makes sense.

Method 1: Python (already on your machine)

If you have Python installed, you already have a JSON formatter:

# pretty-print a file
import json

with open("data.json") as f:
    data = json.load(f)

print(json.dumps(data, indent=2, sort_keys=True))

Validation comes free: if the file is broken, json.load() raises a JSONDecodeError with the exact line and column — I've found this more precise than some IDE plugins.

One-liner version for quick checks:

python3 -m json.tool data.json

Method 2: Node.js

Node has no built-in pretty printer, but it's one line of code:

node -e "console.log(JSON.stringify(require('./data.json'), null, 2))"

Or inside a script:

const fs = require("fs");
const raw = fs.readFileSync("data.json", "utf8");
try {
  const data = JSON.parse(raw);
  console.log(JSON.stringify(data, null, 2));
} catch (e) {
  console.error("Invalid JSON:", e.message);
}

Method 3: In the browser (no install, no upload)

Sometimes you don't want to touch the terminal — you're reviewing a snippet from a chat, or you're on a machine where you'd rather not run unknown files. That's where a browser-based formatter shines.

I use a free online JSON formatter for this: paste the text, it validates and pretty-prints instantly with syntax highlighting, and because everything runs client-side, the data never leaves your browser. That last part matters more than people realize — plenty of API responses contain tokens, customer data, or keys you shouldn't paste into a random server.

The same site has sibling tools I keep pinned, like a Base64 encoder/decoder and a URL encoder — handy when you're debugging JWT payloads or query strings alongside your JSON.

Common mistakes worth knowing

1. Trailing commas. Valid in JavaScript objects, fatal in JSON:

{
  "name": "Ada",
  "role": "engineer",   // ← this comma breaks strict JSON parsers
}

2. Single quotes. JSON strings use double quotes only. '{"a": 1}' is not JSON, it's a JavaScript expression that happens to look like one.

3. Unescaped control characters. Copy-pasted text from PDFs or logs often contains invisible characters like U+00A0. A validator will catch them; your eyes usually won't.

4. Assuming JSON5 or JSONC. Config files for VS Code or tsconfig allow comments (jsonc), but the JSON you send over an API does not. Stripping comments before validating saves an hour of confusion.

Which method should you use?

Situation	Best pick
Scripting, CI pipelines, large files	Python / Node
Quick manual check with sensitive data	Browser-based formatter
Debugging alongside another encoding (Base64, URL)	Browser toolchain

For day-to-day debugging I've settled on the browser for anything small and the terminal for anything batch. The exact split matters less than always validating before you ship — a broken JSON file caught locally costs nothing; caught in production, it costs a pager alert.

More free browser-based developer utilities at utilvy.com — everything runs client-side, no signup.

DEV Community: meng meng

Base64 Encoder / Decoder: Encode UTF-8 Text Without Corrupting Unicode

Base64 Encoder / Decoder: Encode UTF-8 Text Without Corrupting Unicode

Method 1: encode UTF-8 safely with Node.js

Method 2: use Python for strict validation

Method 3: use an online encoder for one-off values

Common pitfalls I have actually hit

1. Calling btoa() directly on Unicode

2. Losing the padding

3. Mixing Base64 and Base64url

Quick comparison

Case Converter: Turning snake_case API Keys Into camelCase Without Breaking Acronyms

Method 1: a Python script that walks the JSON (Python 3.11)

Method 2: Node, for when the repo is already JS (Node 22.13.1)

Method 3: when you just have one blob of text

Three gotchas that cost me real time

Picking an approach

Word Counter for Writers: Counting Words, Characters and Reading Time in Python, Shell, and the Browser

Word Counter for Writers: Counting Words, Characters and Reading Time in Python, Shell, and the Browser

Three tools, three different numbers

Method 1: a Python script you actually keep

Method 2: one line in the shell

Method 3: paste it into a browser tab

Four things that will bite you

Which one when

How to Format and Validate JSON Without Installing Anything

Method 1: Python (already on your machine)

Method 2: Node.js

Method 3: In the browser (no install, no upload)

Common mistakes worth knowing

Which method should you use?

1. Calling `btoa()` directly on Unicode