Every developer accumulates a mental list of small, repetitive tasks that eat into focus time. Renaming a batch of API fields. Converting a CSV export into JSON. Checking a Base64 payload. Running a quick MD5 hash on a string. None of these are hard — but context-switching to a terminal, writing a one-off script, or hunting for a trustworthy online tool all have a cost.
Over the past year I built TextCaseConverters.com — a collection of 94 browser-based text tools — largely because I kept reaching for tools I couldn't find in one place, or tools that uploaded my data to a server I didn't trust. Along the way I learned a lot about the technical standards these tools are actually built on. This article covers the tools I use most, the standards behind them, and why running them in the browser matters more than it might seem.
Case Conversion: More Than Just .toLowerCase()
The obvious tools. But the interesting part is what they get wrong when implemented carelessly.
camelCase and snake_case tokenization
A naive camelCase converter splits on spaces. That works for "hello world" → helloWorld. But what about "parseHTTPResponse"? A tokenizer that doesn't handle acronyms produces parsehttpresponse instead of parseHttpResponse.
A proper tokenizer needs to handle:
- camelCase input → split before each uppercase letter
- PascalCase → same, treating first character as a word start
- Consecutive uppercase runs (HTTP, URL, ID) as a single token
function tokenize(str) {
return str
.replace(/([a-z])([A-Z])/g, '$1 $2')
.replace(/([A-Z]+)([A-Z][a-z])/g, '$1 $2')
.toLowerCase()
.split(/[\s_\-\.]+/)
.filter(Boolean);
}
This is the tokenizer I ended up shipping. It correctly handles parseHTTPResponse → ["parse", "http", "response"] so you get parseHttpResponse in camelCase and parse_http_response in snake_case.
Rust and Go care about your casing
In Go, an uppercase-first identifier is exported from the package. HandleRequest is public; handleRequest is package-private. This isn't convention — it's the language spec. PascalCase converters are a legitimate Go workflow tool.
In Rust, snake_case is enforced by the compiler. A function named handleRequest triggers a non_snake_case lint warning unless you add #[allow(non_snake_case)]. A good snake_case converter removes the need to ever write that attribute.
Base64 — RFC 4648
Base64 is everywhere: JWT payloads, MIME email attachments, data URIs, Basic Auth headers. The standard is RFC 4648. What developers often don't realise is that there are two variants:
- Standard Base64 — uses + and /, may include = padding
- URL-safe Base64 — uses - and _ instead, safe in query strings and JWT headers without percent-encoding
When debugging a JWT, the header and payload use URL-safe Base64 without padding. Pasting one into a standard Base64 decoder can fail silently or produce garbage. A tool that labels which variant it's decoding saves debugging time.
URL Encoding — RFC 3986
Percent-encoding is defined in RFC 3986. The key detail most developers miss: different parts of a URL have different encoding rules.
- In a path segment, / is a delimiter and must not be encoded; spaces become %20
- In a query string, + is traditionally decoded as a space (application/x-www-form-urlencoded), but RFC 3986 percent-encoding uses %20
So encodeURIComponent() in JavaScript encodes everything except A-Z a-z 0-9 - _ . ! ~ * ' ( ). encodeURI() leaves valid URI characters alone. They are not interchangeable, and using the wrong one is a common source of broken redirect URLs.
MD5 — and Why Browser Hashing Matters
MD5 is cryptographically broken for security purposes but still widely used for checksums, cache keys, and Gravatar identifiers. Running it in the browser means the string never leaves your machine.
Worth noting: the Web Crypto API supports SHA-1, SHA-256, SHA-384, and SHA-512 natively. MD5 requires a JavaScript implementation since it was deprecated for security reasons. For anything security-sensitive, use SHA-256.
Unicode Text Tools: What's Actually Happening
Bold and Italic Text That Pastes Anywhere
When you see bold text in a Twitter bio or Discord message, it's not CSS font-weight: bold. Those are characters from the Mathematical Bold Unicode block (U+1D400–U+1D433). Similarly, italic characters in plain text fields come from the Mathematical Italic block (U+1D434–U+1D467).
This matters because:
- They survive copy-paste into any plain text field
- Screen readers may announce them differently (accessibility concern)
- They are not the same characters as their ASCII equivalents — 𝗔 (U+1D5D4) is not A (U+0041)
Strikethrough and Combining Diacritics
Strikethrough text works differently. There is no "strikethrough A" in Unicode. Instead, strikethrough uses combining diacritic marks — specifically U+0336 (COMBINING LONG STROKE OVERLAY) — attached to each character:
A + U+0336 = A̶
Because it's a combining character, it attaches to numbers, punctuation, and emoji too. 1̶2̶3̶ works. The same mechanism is used by Zalgo text, which stacks multiple combining marks vertically to create the "glitchy" horror aesthetic.
Upside-Down Text — Not a CSS Transform
Flipped characters like ʇxǝʇ are individual Unicode characters, not CSS transform: rotate(180deg). Each character maps to a specific Unicode code point that visually resembles the flipped version. They paste into plain text fields, SMS, usernames, and anywhere else a CSS transform wouldn't work.
Formatter vs. Validator
A JSON formatter that only pretty-prints is half a tool. The more useful behaviour is to validate first and surface the exact location of the first syntax error. JSON's most common errors:
- Trailing commas ({"a": 1,}) — valid in JavaScript, invalid in JSON
- Single-quoted strings — valid in JS, invalid in JSON
- Unquoted keys — valid in JS object literals, invalid in JSON
- Comments — valid in JSON5/JSONC, not in standard JSON
JSON.parse() throws with a position offset when it hits an error. A good formatter catches that and highlights the problematic line.
JSON Stringify vs. JSON Minify
These are different operations developers sometimes confuse:
- Minify: Remove whitespace and newlines from formatted JSON. {"name": "Alice"} → {"name":"Alice"}. Same data, smaller payload.
- Stringify: Escape a JSON object so it becomes a valid JSON string value. {"name":"Alice"} → "{\"name\":\"Alice\"}". Used when embedding JSON inside JSON — a common pattern in API responses that wrap a serialized payload.
Password Generation: Why Math.random() Is Wrong
Math.random() is not cryptographically secure. It's seeded deterministically and its output can be predicted given enough samples. For password generation, the correct API is:
const array = new Uint32Array(1);
window.crypto.getRandomValues(array);
window.crypto.getRandomValues() uses the operating system's CSPRNG (Cryptographically Secure Pseudo-Random Number Generator) — the same source used by crypto.randomBytes() in Node.js.
For passphrases, the gold standard is the EFF Large Wordlist — 7,776 words selected specifically for memorability and unambiguity (no words that sound alike). Five words from this list gives ~64 bits of entropy, which is considered strong for most purposes.
Why Browser-Only Processing Matters
Every tool I described above runs entirely client-side. No server receives your input. This matters for several real use cases:
- API keys and credentials: You're debugging a JWT or Base64-encoded secret. Pasting it into a server-side tool means it traverses the internet and lands in someone's access log.
- Pre-publication content: A client article, an unreleased product name, internal documentation — these shouldn't be on a third-party server.
- Proprietary code: Normalising database column names or reformatting JSON config files from internal systems.
The browser is a surprisingly capable runtime for text processing. TextEncoder, TextDecoder, the Web Crypto API, and the full Unicode character set are all available without any libraries or installs.
A few things I didn't expect when building 94 of these:
Unicode is enormous. There are 17 planes, and most tools only need Plane 0 (Basic Multilingual Plane) and a slice of Plane 1 (Supplementary Multilingual Plane). But correctly handling emoji, combining characters, and surrogate pairs requires treating strings as code points, not char codes.
The Fisher-Yates shuffle is underused. Most developers reach for array.sort(() => Math.random() - 0.5). It's biased — some permutations are more likely than others. Fisher-Yates, implemented with crypto.getRandomValues(), produces a uniform distribution.
Readability scores are easy to misread. Flesch-Kincaid Grade Level of 12 doesn't mean "bad writing" — it means a 12th-grade reading level. Technical documentation is expected to score high. The score is only meaningful relative to your target audience.
If you want all of this in one place without installing anything: TextCaseConverters.com — 94 tools across case conversion, encoding, JSON, Unicode text, analysis, and password generation. Everything runs in your browser.
Bookmark the ones you reach for, or keep the homepage open as a starting point. No account, no signup, no data sent anywhere.
Foysal Mostafa is a developer and tool builder. TextCaseConverters.com is a free, open-to-all tool suite built for developers and writers.
