Base64 Tool
Encode and decode Base64 strings instantly in your browser. Supports standard and URL-safe Base64. No data leaves your device.
About Base64
Base64 encodes binary data as ASCII text using 64 printable characters. It's commonly used in data URIs, JWTs, email attachments (MIME), and API payloads. URL-safe Base64 replaces + and / with - and _ to avoid conflicts in URLs and filenames.
About This Tool
Base64 turns binary data into text safe for transport through systems that only accept text — JSON, URLs, email, HTTP headers. The encoding is straightforward in concept (groups of three bytes become four ASCII characters from a 64-character alphabet) but tedious to do by hand, and most languages have one-line built-ins that few people remember the exact name of.
Paste text or upload a file, and the tool encodes to base64. Or paste base64 and decode back to text or download as binary. Both directions support standard base64 (with + and / characters) and url-safe base64 (using - and _ instead, since + and / have meaning in URLs). Padding is handled correctly — the trailing = characters that pad to a four-character boundary.
Most people use it for embedding small images in CSS or JSON, decoding tokens that turn out to be base64-wrapped, or sanity-checking the output of an API that claims to return base64-encoded content. The encoding adds about 33% to data size, so it's not for large payloads.
The encoding scheme is a six-bit-to-character mapping: take three bytes of input (24 bits), split into four six-bit groups, map each group to a character from the 64-character alphabet (A-Z, a-z, 0-9, +, /). When the input length isn't a multiple of three, the encoder pads with one or two = characters to keep the output length divisible by four. The decoder reverses this exactly. The encoding is deterministic, lossless for binary input, and has no entropy or compression — the output is purely a re-representation of the input bytes in text form.
Worked example: encoding "Hi!" (three bytes: 0x48, 0x69, 0x21). Binary: 01001000 01101001 00100001 = 24 bits. Split into 6-bit groups: 010010 000110 100100 100001 = decimal 18, 6, 36, 33. Map to alphabet: S, G, k, h. Output: "SGkh". No padding needed because input was exactly three bytes. Now encode "Hi" (two bytes): 01001000 01101001 = 16 bits. Pad to 24 bits: 01001000 01101001 00000000. Groups: 010010, 000110, 100100, 000000. Map: S, G, k, A. But the last group came from padding, so add one = to indicate: "SGkA=". The decoder ignores the padded zero bits and returns just "Hi".
Limits worth flagging: the 33% size overhead is intrinsic. For text data, this is negligible; for large binary files, it matters. A 10 MB image becomes 13.3 MB encoded. For HTTP transport, gzip compression after Base64 helps but doesn't fully recover the overhead. For embedding small images in HTML/CSS as data URLs, Base64 is fine; for large media, native binary upload (multipart/form-data, raw POST) is dramatically more efficient. Don't Base64 a 100 MB video to embed it; serve the file directly.
The URL-safe variant exists because + and / have meaning in URLs (+ encodes to space in query strings, / separates path segments). URL-safe Base64 (sometimes called Base64URL or Base64URLSafe) uses - and _ instead. The padding character = is also problematic in URLs (it's the parameter separator), so URL-safe variants often omit padding entirely and reconstruct length from context. JWTs use unpadded Base64URL for header and payload encoding precisely because they travel in URLs and HTTP headers where standard Base64 would break.
The about text and FAQ on this page were drafted with AI assistance and reviewed by a member of the Coherence Daddy team before publishing. See our Content Policy for editorial standards.