Base64 Encode / Decode

Base64 is a way to represent arbitrary binary data using only 64 printable ASCII characters (A–Z, a–z, 0–9, + and / ). This Base64 encoder and decoder groups the input into 3-byte chunks and re-encodes each as four characters, padding the final group with = . It exists so binary can travel safely through text-only channels — email bodies, JSON, data URIs, HTTP headers.

Encoding is not encryption. Base64 is fully reversible by anyone, with no key involved — it adds zero secrecy and grows the payload by about a third. The URL-safe variant swaps +// for -/_ and usually drops padding, so the value survives inside URLs and filenames. Everything here runs in your browser; the text and files you convert never leave your machine.

Text is converted to UTF-8 bytes first, then encoded. Some typical results:

Three bytes always become four characters, so Hi! needs no padding, while hello (5 bytes) ends with one =. The accented é is two bytes in UTF-8, which is why it encodes to four characters rather than two. The last row shows the URL-safe alphabet replacing / and + and dropping the padding.

Not a secret: HTTP Basic credentials

Encoding user:pa55word gives dXNlcjpwYTU1d29yZA==, the value sent in an Authorization: Basic header. Switching to Decode reverses it instantly, which is why Basic authentication is only safe over HTTPS.

• Encoded / Decoded — the conversion succeeded. When encoding a file, the verdict includes the file name.
• Decoded · binary — the bytes are valid Base64 but not valid UTF-8 text (an image, archive or compressed data). The output pane shows the byte count instead of garbled characters; use Download to save the raw bytes.
• Invalid Base64 — decoding failed; the message names the problem (see troubleshooting below).
• In / out / ratio — byte sizes before and after, and the change as a percentage. Encoding hello shows 5 B in, 8 B out, +60%; longer inputs approach +33%, plus one byte per line break when Wrap 76 is on. Decoding shows a negative ratio.
• Download — saves encoded output as encoded.base64.txt (or <file name>.base64.txt for files) and decoded bytes as decoded.bin.

• Data URIs. Encode a small icon with the File source, then prepend the prefix yourself, for example data:image/png;base64,, to inline it in HTML or CSS.
• Config and secrets files. Kubernetes Secret data fields and many CI variables expect Base64; decode them to check what is really stored.
• API payloads. Put binary data such as a certificate or a small attachment inside JSON, or decode a Base64 field from an API response and inspect it with the JSON Formatter.
• Tokens and URLs. Use URL-safe output for values placed in query strings or file names. JWT segments are URL-safe Base64 too; the JWT Decoder splits and decodes them for you.
• Email attachments. Wrap 76 breaks the output into 76-character lines, the line length used for Base64 in MIME email bodies.

Spaces and line breaks in pasted Base64 are ignored, missing = padding is added back, and input containing - or _ is treated as URL-safe automatically, so wrapped MIME text and unpadded tokens decode without editing.

• Text is always encoded as UTF-8, and decoded output is shown as text only when it is valid UTF-8. There is no option for other character sets.
• Files can be loaded for encoding only; to decode, paste the Base64 text. The tool does not build or strip data: URI prefixes.
• URL-safe and Wrap 76 apply to encoding. Wrapped lines use a single line feed (LF) and a fixed width of 76 characters.
• Files are processed in browser memory, so very large files are limited by your device rather than by a server-side cap.
• The decoder accepts Base64 without padding, so it is more lenient than strict decoders that reject unpadded input. Base64 offers no integrity check — a corrupted but well-formed string decodes to wrong bytes without an error.