Base64 Encoder / Decoder

Base64 is an encoding scheme that converts binary data into a string of plain ASCII characters. It's used everywhere in computing: embedding images in HTML/CSS, encoding email attachments, transmitting binary data in JSON APIs, storing binary data in text-based formats, and encoding data in URLs and HTTP headers. Base64 is not encryption — it's just a different representation of the same data. This tool encodes any text you type into Base64 and decodes a Base64 string back to readable text, with a live character/byte count and the size change shown as you go.

It's aimed at developers, students and anyone who works with web APIs: inspecting a JWT payload, decoding a value copied out of an HTTP header or a config file, hand-building a small data URI for an icon, or just checking what a mysterious-looking string actually contains. Full Unicode is supported, so Hindi, Tamil, Bengali or emoji round-trip correctly — the tool encodes text as UTF-8 first, so a single Devanagari character (which takes 3 bytes in UTF-8) expands accordingly in the output.

How Base64 Works

Base64 takes every 3 bytes of input (24 bits) and converts them into 4 ASCII characters chosen from a 64-character alphabet (A–Z, a–z, 0–9, +, /). The 24 bits are simply re-grouped into four 6-bit chunks, and each 6-bit value (0–63) indexes into that alphabet: 0–25 map to A–Z, 26–51 to a–z, 52–61 to 0–9, 62 to + and 63 to /. Because 6 bits can represent 64 values, four output characters carry exactly 24 bits — the same information as the three input bytes, just spread over more, safer characters. If the input length isn't a multiple of 3, padding characters (=) are appended to round the output up to a multiple of 4. This is why Base64 output is always about 33% larger than the original — every 3 input bytes become 4 output characters.

Worked example — encoding "Hi"

Take the two characters Hi. In ASCII, H is 72 (binary 01001000) and i is 105 (binary 01101001), giving 16 bits: 0100100001101001. Base64 needs groups of 6 bits, so it pads the 16 bits to 18 with two zero bits and splits them into three 6-bit values:010010 = 18 → S, 000110 = 6 → G, and1001(00) = 36 → k. That accounts for only two of the four output slots, and since one input byte was “missing” from the 3-byte group, a single= pad is added. The result is SGk=. Decoding reverses every step to recover “Hi”.

URL-Safe Base64

Standard Base64 uses + and / which have special meaning in URLs. URL-safe Base64 (Base64url) replaces + with - and / with _, making it safe for use in URLs and filenames without percent-encoding. JWTs (JSON Web Tokens) use Base64url encoding. If your Base64 string will appear in a URL, use the URL-safe variant and replace = padding with nothing or with %3D.

Tips

• Use the live byte count to predict payload size before sending — Base64 inflates data by ~33%, which matters for large data URIs or mobile API calls.
• To decode a JWT, paste only the middle segment (between the two dots) into Decode; each of the three JWT parts is encoded separately.
• Trim any stray whitespace or line breaks before decoding — they are a common cause of “invalid Base64” errors.
• Encoding is reversible by anyone, so never use it to hide passwords or secrets; encode for transport, encrypt for security.

Common mistakes

• Treating Base64 as security. It offers none — anyone can decode it instantly.
• Mixing standard and URL-safe alphabets. A token using - and _ will fail in a standard decoder, and vice versa.
• Dropping the = padding. Some decoders are strict and need the padding to reach a length that is a multiple of 4.
• Expecting binary files here. This tool encodes and decodes text; for images or PDFs, use a command-line tool such as base64 filename.