Text Tools Explained: Case, Slugs, Encoding, and Clean Data Formats

Text tools are the quiet workhorses of a normal day: you need a heading turned into a clean URL, a caption counted against a character limit, a copied value that has to survive a trip through a web address, or the same little table moved from a spreadsheet into an API. None of it is hard, but all of it is easy to get subtly wrong — a stray accent, a comma inside a field, a space that should have been %20. This guide explains the five text jobs people do most often, shows exactly what happens to the characters (every example here is computed and checked), and flags the gotchas that produce broken output. When you just need the result, a free in-browser tool does the transformation instantly — but once you can see the mechanics, you'll trust the output and catch a bad one.

Changing case: from Title Case to snake_case

Case conversion looks trivial until you realise there are two families of it. The human cases are about reading: UPPERCASE, lowercase, Sentence case, and Title Case. The programmer cases are about turning a phrase into a single identifier with no spaces, because most code and config can't contain spaces.

Take the phrase user profile image and run it through both families:

The one gotcha in human case

Title Case and Sentence case both look simple — capitalise the first letter — but Title Case has an editorial rule most tools skip: small joining words (a, an, the, of, and, to, in) usually stay lowercase unless they start the title. "The Lord of the Rings", not "The Lord Of The Rings". A naive "capitalise every word" converter gets this wrong, so if a title matters, check the small words by eye. Sentence case has the opposite trap: it should leave proper nouns (names, brands, places) capitalised, which a blind lowercase-then- capitalise-first pass will flatten.

Programmer cases are mechanical

The programmer cases are pure rearrangement: split the phrase into words, then join them with a fixed rule. camelCase joins with no separator and capitalises every word after the first; PascalCase capitalises the first too; snake_case and kebab-case join with _ or - and lowercase everything. Because the rule is exact, this is the safest kind of conversion to automate — the only ambiguity is what counts as a "word" when the input already has punctuation or mixed case.

Slugs: turning a title into a URL

A slug is the human-readable tail of a web address — the text-tools-guide part of this page's URL. Making one is really four steps applied in order:

1. Lowercase everything.
2. Strip accents and diacritics so é becomes e, ü becomes u.
3. Replace every run of non-alphanumeric characters (spaces, punctuation, symbols) with a single hyphen.
4. Trim any leading or trailing hyphens.

Worked example — the messy title Hello, World! Café:

Hello, World! Café → lowercase → hello, world! café → strip accents → hello, world! cafe → non-alphanumeric to hyphens → hello-world-cafe

Note that the comma, the exclamation mark, and the double space all collapse into single hyphens, and the accent on the é is folded down to a plain e so the URL stays ASCII-safe. That accent-folding step is the one people forget: leave it out and you get caf%C3%A9 in the address bar (see URL encoding below), which works but reads like a mistake.

Counting text: words, characters, and why the numbers disagree

"How long is this?" has three different answers, and mixing them up is why a caption that a counter says fits still gets rejected.

• Words are runs of non-space characters separated by whitespace. Simple — until you ask whether a hyphenated "state-of-the-art" is one word or four. Most counters treat it as one; most people reading aloud would say four.
• Characters with spaces counts every keystroke, spaces included. This is what social and SMS limits almost always mean.
• Characters without spaces counts only visible glyphs. This is what some academic and print limits mean.

The gotcha: characters are not bytes

Here's the trap that breaks database fields and API limits. A character is what you see; a byte is how it's stored. In UTF-8, the standard text encoding of the web, plain English letters take one byte each, but accented and non-Latin characters take more. The word café is 4 characters but 5 bytes, because the é is stored as two bytes. Emoji are worse — a single emoji can be four bytes or more. So a field that allows "255 characters" but is really measured in bytes will reject a message that looks well under the limit. When a limit feels wrong, check whether it's counting characters or bytes.

Encoding: making text safe to travel

Encoding isn't about secrecy — it's about survival. Some characters have special meaning inside a URL or an email, so before text can travel there it gets rewritten into a form that can't be misread. Two encodings cover almost every everyday case.

URL encoding (percent-encoding)

A web address can't contain spaces, and characters like &, ?, and # are reserved as separators. Percent-encoding (defined by RFC 3986) replaces any unsafe character with a % followed by its byte value in hexadecimal. A few you'll see constantly:

So the search phrase a b becomes a%20b, and café becomes caf%C3%A9. That last one shows why encoding and UTF-8 are linked: the %C3%A9 is exactly the two bytes UTF-8 uses to store é. Decode reverses it, one %xx at a time.

Base64

Base64 (RFC 4648) solves a different problem: sending binary data — images, keys, any bytes — through a channel that only reliably carries plain text. It reads the input three bytes (24 bits) at a time and re-slices those 24 bits into four 6-bit chunks, each mapped to one of 64 safe characters (A–Z, a–z, 0–9, +, /).

Man → bytes 77, 97, 110 → TWFu (a clean 3-byte input, no padding)

When the input isn't a multiple of three bytes, Base64 pads the output with = so the length stays a multiple of four:

Hi → 2 bytes → SGk= (the trailing = marks one byte of padding)

Two things to remember: Base64 makes data bigger, not smaller — roughly a third larger — so it's for safe transport, not compression. And it is not encryption; anyone can decode it back to the original in one step.

Data formats: the same table in JSON, CSV, and YAML

The last text job is moving structured data between the three formats you'll actually meet. They can carry the same information; they just suit different readers. Here is one small record in all three:

JSON — the language of web APIs, good at nesting:

{"name": "Ada", "active": true, "score": 9}

CSV — the language of spreadsheets, flat rows and columns:

name,active,score
Ada,true,9

YAML — the language of config files, easiest for humans to edit:

name: Ada
active: true
score: 9

Each has one classic gotcha. CSV: if a value itself contains a comma ("Lovelace, Ada"), it must be wrapped in double quotes, or the row splits into the wrong number of columns — the single most common cause of a broken import (RFC 4180 defines the quoting rule). JSON: no trailing comma after the last item and no comments allowed; both are the usual reason a copied snippet won't parse. YAML: whitespace is significant, so a stray tab or a misaligned indent changes the meaning — and unquoted words like no, off, and yes can be read as booleans instead of text (the so-called "Norway problem", where the country code NO becomes false). When a value must stay text, quote it.

The short version

Case conversion is rearranging words; slugs are lowercase-fold-hyphenate; counting has three honest answers and characters are not bytes; URL and Base64 encoding rewrite text so it can travel; and JSON, CSV, and YAML are three spellings of the same data with three different gotchas. Learn the mechanics once and you'll never be surprised by the output. For the day-to-day, a free converter does each of these instantly — which is exactly what Medley Web is building.

FAQ

Is Base64 a way to hide or encrypt text? No. Base64 is an encoding, not encryption — it only reshapes bytes into text-safe characters, and anyone can decode it back to the original in one step. Use it to transport data safely, never to protect a secret.

Why does my text hit a character limit when it looks short? The limit is probably counting bytes, not characters. In UTF-8, accented letters and emoji take more than one byte each, so a field that says "255 characters" but measures bytes will reject text that looks well under the count. Check whether the limit is characters or bytes.

What's the difference between camelCase and snake_case? They're two ways to join words into a single identifier with no spaces. camelCase capitalises each word after the first (userProfileImage); snake_case lowercases everything and joins with underscores (user_profile_image). They carry the same words — only the separator and capitalisation differ.

Why do spaces sometimes show up as %20 in a link? That's URL encoding. Web addresses can't contain spaces, so each space is replaced by %20 (its byte value in hex) to keep the link valid. Decoding turns it back into a space.

Which format should I use — JSON, CSV, or YAML? Use CSV for flat, spreadsheet-style tables; JSON for data with nesting or for web APIs; and YAML for human-edited config files. They can hold the same information, so pick the one that matches who or what reads it next.

Ready to stop doing this by hand? Clean up and convert text free at medley-web.com — change case, make slugs, count words, encode for URLs and Base64, and move data between JSON, CSV, and YAML in your browser.