# Base64, Base32, Hex & Percent Codec > Encode text to Base64, URL-safe Base64, Base32, hexadecimal, or percent-encoding, and decode any of them back. Tolerant of missing padding and whitespace, and it flags binary (non-UTF-8) results. Runs entirely in your browser. - Tool: https://ronutz.com/en/tools/base64 - Family: Encoding & data --- ## What it does This is a two-way codec for five text encodings. Enter text and it returns the Base64, URL-safe Base64, Base32, hexadecimal, and percent-encoded forms at once; enter an encoded string and it decodes back to text. Decoding is tolerant: missing padding and stray whitespace are accepted, and when a decoded byte stream is not valid UTF-8 text, the result is flagged as binary rather than shown as broken characters. Everything runs in your browser; nothing is uploaded. ## The five encodings All five map between text (as bytes) and an ASCII-safe representation, each defined by a standard: - **Base64** (RFC 4648, section 4) uses the alphabet `A-Z a-z 0-9 + /` and pads with `=`. It grows data by about a third and is the encoding behind HTTP Basic credentials, `base64(user:password)`, defined in RFC 7617. - **URL-safe Base64** (RFC 4648, section 5) swaps `+` and `/` for `-` and `_` and usually drops the `=` padding, so the string is safe inside URLs and filenames. It is the encoding each segment of a JWT uses. - **Base32** (RFC 4648, section 6) uses `A-Z 2-7` and pads with `=`. It is case-insensitive and avoids easily-confused characters, which is why it shows up in places like TOTP secrets. - **Hexadecimal (Base16)** (RFC 4648, section 8) uses `0-9 A-F`, two characters per byte. - **Percent-encoding** (RFC 3986, section 2) keeps the unreserved set (`A-Z a-z 0-9 - . _ ~`) as-is and encodes every other byte as `%XX`. This is URL encoding. ## Padding, whitespace, and binary results Base64 and Base32 are normally padded with `=` to a whole number of blocks, but real-world strings often arrive with the padding stripped or with line breaks inserted, so the decoder accepts both. When you decode a value whose bytes do not form valid UTF-8 text (a compressed blob, an image, a raw key), the tool tells you the result is binary instead of rendering it as broken text, so you know the decode worked even though the payload is not human-readable. ## Worked examples - The text `hello` becomes Base64 `aGVsbG8=`, URL-safe Base64 `aGVsbG8`, Base32 `NBSWY3DP`, hex `68656c6c6f`, and percent-encoding `hello` (all of its characters are unreserved). - Decoding the Base64 value `dXNlcjpwYXNz`, a typical HTTP Basic credential, returns `user:pass`. ## Using it Enter text to see all five encodings side by side, or paste an encoded value to decode it. Because the codec is a pure function of its input, the same text always produces the same output. ## Standards and references - [RFC 4648 - The Base16, Base32, and Base64 Data Encodings](https://www.rfc-editor.org/rfc/rfc4648) - base64 (section 4), base64url (section 5), base32 (section 6), base16/hex (section 8) alphabets and padding - [RFC 3986 - Uniform Resource Identifier (URI): Generic Syntax](https://www.rfc-editor.org/rfc/rfc3986) - percent-encoding (section 2.1) and the unreserved set (section 2.3) - [RFC 7617 - The Basic HTTP Authentication Scheme](https://www.rfc-editor.org/rfc/rfc7617) - base64(user:password) - a common reason to decode base64 ## Related reading - [Base16, Base32, Base64, and percent-encoding compared](https://ronutz.com/en/learn/text-encodings-compared.md): A side-by-side look at the four text encodings: their alphabets, size overhead, readability, and when to reach for each. - [Base32, explained](https://ronutz.com/en/learn/base32.md): Why Base32 trades size for a case-insensitive, unambiguous alphabet, how its 5-bit grouping works, and where it shows up (TOTP secrets, onion addresses, DNS). - [Base64 and Base64URL, explained](https://ronutz.com/en/learn/base64.md): How binary data becomes safe-to-transmit text, why padding exists, and what changes in the URL-safe variant. - [Base64URL and the URL-safe alphabet](https://ronutz.com/en/learn/base64url.md): Why JWTs and PKCE use a different Base64 alphabet, the two characters that change, and what happens to the padding. - [Bytes, code points, and UTF-8](https://ronutz.com/en/learn/character-encoding.md): The difference between a character and a byte, why Unicode and UTF-8 exist, and what that has to do with Base64. - [Evasion Techniques: How Advanced WAF Normalizes Around Attacker Encoding](https://ronutz.com/en/learn/awaf-evasion-techniques.md): Attackers hide payloads inside unusual encodings so a signature never sees the real characters. BIG-IP Advanced WAF answers with eight evasion sub-violations under the single 'Evasion technique detected' violation, each normalizing or detecting one trick: %u decoding, Apache whitespace, Bad unescape, Bare byte decoding, Directory traversals, IIS backslashes, IIS Unicode codepoints, and Multiple decoding. All eight are enabled by default. - [Hashing, encryption, and encoding: three different things](https://ronutz.com/en/learn/hashing-encryption-encoding.md): Three operations that get constantly confused, separated cleanly by two questions: is it reversible, and does it need a key? - [Hexadecimal encoding (Base16), explained](https://ronutz.com/en/learn/hex-encoding.md): How hex represents each byte as two characters, why it is the default way to print raw bytes, and how it compares to Base64 and Base32. - [Percent-encoding (URL encoding), explained](https://ronutz.com/en/learn/percent-encoding.md): Why URLs escape certain characters as %XX, which characters are safe to leave alone, and how percent-encoding differs from Base64. - [Where Base64 shows up: data URIs, MIME, PEM, and Basic auth](https://ronutz.com/en/learn/base64-in-practice.md): The real places binary gets wrapped in text, the size cost of doing it, and why Base64 in an auth header is not encryption.