People use "encoding" for several different operations. Some are reversible and some are one-way. Some turn bytes into text; others turn text into an identifier. This page separates them, starting with the distinction that causes the most confusion: encoding, hashing, and encryption are three different things, not three words for one idea.
Base64 is reversible, and anyone can reverse it
Base64 represents arbitrary bytes as printable ASCII text, using a 64-character alphabet plus padding so the output length is always a multiple of 4. Decoding always recovers the exact original bytes. That's also why it provides no confidentiality: anyone can decode it. It's an encoding, not a cipher. It exists because some transports and file formats can't safely carry raw binary (control characters, null bytes) but can carry printable text.
The Base64 Encode / Decode tool handles full Unicode correctly, which trips up naive implementations. The full guide shows where that quietly breaks.
There's also a variant to know by name. Standard Base64's alphabet includes + and /, and both mean something in a URL. Base64URL swaps them for - and _ and drops the padding, so the result can go straight into a URL path or query string without another round of URL-encoding. The two aren't interchangeable without converting. Decode a Base64URL string with a strict standard-Base64 decoder (or the other way round) and it fails or produces the wrong bytes, because each alphabet is missing the other's two characters. The Base64 vs Base64URL guide covers which contexts expect which. JWTs, for example, use Base64URL, which is behind a lot of "why won't this decode" questions.
Hashing, HMAC, and encryption
These three get mixed up in conversation, and they do different things. Encoding (Base64, above) is reversible by design; decoding is the point. Hashing (MD5, SHA-1, SHA-256, and SHA-512, all in the Hash Generator) is one-way by design. There is no "unhash," and a good hash function is built so you can't reconstruct the input from the output. Encryption is a third thing. It's reversible like encoding, but reversing it requires a secret key, which neither plain encoding nor plain hashing involves. Calling hashing, HMAC, or Base64 "encryption" is a common mistake. Beyond all turning input bytes into different output bytes, they have little in common.
Which hash to use is a security question, not a length or speed trade-off, so don't just pick the newest one by reflex. MD5 has had practical collision attacks (two different inputs deliberately built to produce the same digest) since the mid-2000s. SHA-1 went the same way: Google and CWI Amsterdam published a practical SHA-1 collision in 2017 ("SHATTERED"), and major browsers and certificate authorities had already phased SHA-1 out of TLS certificates before that.
Both are still fine where nobody is trying to forge a collision: a checksum for accidental corruption, a cache key, a quick fingerprint. Neither belongs anywhere security depends on collisions being infeasible, such as passwords, digital signatures, or integrity checks on anything an attacker could tamper with. SHA-256 (and the rest of SHA-2) has no practical collision attack as of this writing and is the default where security matters. The MD5 vs SHA-256 guide has more of the history and the cases where each is the right choice.
HMAC is a hash keyed with a shared secret. That lets you check that a message came from someone who knows the secret and wasn't changed in transit, which is why it sits behind signed webhook payloads and JWT signatures. It's still one-way: you can't recover the message or the key from an HMAC digest. It proves integrity and authenticity, not confidentiality. The digest reveals nothing about the message to someone without the key, but it doesn't hide the message either; that takes separate encryption.
In the Hash Generator, HMAC-SHA256 is a toggle, not a fifth entry in the MD5/SHA-1/SHA-256/SHA-512 list. Turning it on replaces the plain digest with a keyed one (fixed to SHA-256, the practical default from above) and shows a secret-key field. That field is there because an HMAC digest means nothing unless you know which key produced it.
URL encoding and URL parsing
Percent-encoding, which the URL Encoder / Decoder does, replaces characters that aren't safe in a URL component (spaces, &, =, non-ASCII characters) with a %XX escape, so a value can sit inside a URL without clashing with the URL's own delimiters. RFC 3986 defines exactly where the line is.
The unreserved characters are the letters A–Z a–z, the digits 0–9, and - _ . ~. They never need escaping in any part of a URI. The reserved characters come in two groups: : / ? # [ ] @, the "general delimiters" that separate a URI's structural parts, and ! $ & ' ( ) * + , ; =, the "sub-delimiters" used inside a component. Because reserved characters carry structural meaning, whether one needs escaping depends on where it appears. A literal & inside a query parameter's value must be percent-encoded, or it reads as the separator between two parameters. The & characters that separate parameters in the query string are correct as-is. Anything outside both lists, including every non-ASCII character, always needs percent-encoding, usually after being encoded to UTF-8 bytes first.
Spaces are a common trap. Strict RFC 3986 encoding escapes a space as %20. But application/x-www-form-urlencoded, the encoding an HTML form uses for its submitted body (and the format most query strings loosely follow), encodes a space as a literal +. It then requires a literal + in the data to be escaped as %2B so it isn't read as a space. Mixing the two conventions is a recurring bug. Decode a form-encoded value with a strict RFC 3986 decoder and every space comes out as a literal +, with no error. Both encodings are valid, which is why the mismatch is easy to miss.
Parsing a URL means pulling apart the protocol, host, path, and query parameters, which the URL Parser & Query String Builder does. It's decoding plus structure: the parser has to know that everything after ? is the query string, that & separates parameters inside it, and that each value needs percent-decoding before you can use it. The when-and-why guide and the parsing guide treat these separately. Encoding a value correctly and parsing a URL correctly are different skills that both happen to involve percent-escapes.
Case conversion: splitting words is the hard part
Converting between camelCase, snake_case, kebab-case, and PascalCase looks trivial until the input has consecutive capitals, digits next to letters, or inconsistent casing. Re-joining words with a new separator is easy. Splitting the input into words is the hard part: does userID split into user + ID, or user + i + d?
Splitting on capital letters gets this wrong one way or the other. Treat every capital as a word boundary and userID becomes user_i_d instead of user_id. Tune the rule to keep consecutive capitals together and it can mis-split parseHTMLString, where HTMLString should become HTML + String. No context-free rule handles every identifier, so a converter has to pick a heuristic and accept that some inputs need a manual fix. The Case Converter and its companion guide go through where simple splitting rules disagree with what you'd expect.
UUIDs
A UUID doesn't encode anything. It's a 128-bit identifier, generated randomly or partly from a timestamp. It belongs on this page because it solves a neighboring problem: producing a value that's safe to use as an ID without a central authority handing out sequential numbers. The UUID Generator supports v1, v4, v7, and the all-zero nil UUID. v4 is fully random. v1 and v7 both embed a timestamp, so v7 UUIDs sort in roughly creation order. That helps with database primary keys, where v4's randomness works against you by scattering rows across a B-tree index.
The v4 vs v7 guide goes further into that index-locality trade-off. It also covers the privacy side: a v7 UUID reveals roughly when it was generated, while a v4 UUID reveals nothing beyond itself.
Slugs, diacritics, and Unicode
A slug is a restricted-alphabet identifier for a URL path segment or filename: lowercase, hyphen-separated, with nothing a browser or filesystem would need to escape. Naive implementations break on diacritics and non-Latin scripts. Does "café" become cafe (diacritic stripped) or caf (the letter dropped because it fell outside an ASCII-only character class)?
The Slug Generator applies Unicode normalization instead of filtering to [a-z0-9-] and hoping. The diacritics and Unicode guide explains the normalization step: decompose an accented character into its base letter plus a separate combining mark, then drop the mark. That's what makes "strip diacritics" work, as opposed to deleting everything outside ASCII and losing the letter along with its accent.
Color formats
HEX, RGB, and HSL describe the same color space with different coordinates. They're three notations for the same three-dimensional value, not three unrelated formats. HEX and RGB are the same numbers: HEX is RGB written as three hexadecimal byte pairs, so #ff0000 is exactly rgb(255, 0, 0). The 3-digit shorthand, like #f00, doubles each digit; it isn't a lower-precision encoding.
HSL re-expresses the same color as hue, saturation, and lightness. That's easier to reason about ("a bit lighter," "more saturated") than nudging three RGB channels by feel, but going between HSL and RGB takes a max/min-channel conversion formula rather than a relabeling. The Color Picker converts between all three live, and the conversion guide has the formulas.
What these have in common
Most tools on this page exist because a value that's convenient in one place (arbitrary bytes, a query parameter value, a database key, a page title) is unsafe or ambiguous somewhere else (a URL, a filesystem path, a B-tree index, a security check). The encoding is the deterministic translation between the two, reversible or not. Base64 is reversible and not secret. A hash is one-way and not secret either. HMAC is one-way and keyed. Percent-encoding is reversible, and which characters it touches depends on context. Keeping those straight is most of what separates a correct tool from one that only works on the examples you tried.