The encoding, bit by bit
Base64 takes the input as a stream of bytes, groups them in threes (24 bits), and splits each group into four 6-bit values. Each 6-bit value, 0 to 63, indexes a 64-character alphabet: A to Z for 0 to 25, a to z for 26 to 51, the digits for 52 to 61, then + and /. The three bytes of Man are 77, 97 and 110. Their 24 bits regroup as 19, 22, 5 and 46, which index to TWFu.
When the input length is not a multiple of three, the last group is short. Two bytes produce three characters plus one = sign. One byte produces two characters plus ==. That is why Hi becomes SGk= and why a valid Base64 string, ignoring whitespace, always has a length that is a multiple of four once padding is counted. The decoder adds missing padding itself because many producers leave it off.
Text has to become bytes before any of this happens. The tool uses UTF-8, so plain ASCII is one byte per character while an accented letter takes two and most emoji four. Decoding reverses the process and then tries to interpret the bytes as UTF-8. If that fails, the bytes are kept and offered for download instead.
Standard, URL-safe and MIME variants
The standard alphabet includes + and /, both of which have meanings in URLs, and = is a query-string delimiter. RFC 4648 defines base64url for that reason: - replaces +, _ replaces /, and padding is usually dropped. The URL-safe checkbox applies exactly that, so the bytes of >>? encode as Pj4/ normally and Pj4_ in the URL-safe form. JSON Web Tokens, OAuth state values and many API keys use base64url.
MIME email, PEM certificate files and some older systems expect lines of at most 76 characters. The Wrap option inserts a line break after every 76 characters. The decoder removes line breaks on the way back, so wrapped and unwrapped input decode identically. A PEM certificate body is wrapped Base64 of DER bytes, which is what Certificate Decoder unpacks.
What the decoder tells you about a payload
After decoding, the tool inspects the first bytes. A PNG starts with 0x89 followed by PNG, a JPEG with FF D8 FF, a GIF with GIF, a PDF with %PDF and a ZIP (including DOCX, XLSX and JAR files) with PK. A match produces a line such as image/png binary data, 1234 bytes. Images are rendered as a preview and the Download button saves the bytes with a fitting extension. Other binary data is saved as decoded.bin.
If the bytes are valid UTF-8 they are shown as text and Copy becomes available. If they are neither recognised binary nor valid UTF-8, the panel says so and still offers the download, since the bytes may be a file type the tool does not know or text in another encoding. The error Input contains characters that aren't valid Base64 means something outside the alphabet is present, often a stray quote or a truncated copy.
- A data: URI prefix such as data:image/png;base64, is stripped automatically.
- Spaces, tabs and line breaks anywhere in the input are ignored.
- The + / and - _ alphabets are both accepted, even mixed.
- Missing = padding is added before decoding.
Files, data URIs and when not to use them
The File to Base64 panel reads a file from your device and builds a data URI from its MIME type, falling back to application/octet-stream when the browser does not know the type. Copy Base64 gives the bare payload for a JSON field or a database column. Copy data URI gives the whole string for an img src, a CSS url() or a link href. The preview box shows the first 20,000 characters.
Data URIs make sense for small icons and fonts that would otherwise cost an extra request. They are a poor choice for anything large: the data cannot be cached separately from the page, grows by a third, and bloats every document it appears in. For a look at the raw bytes behind a string, Text to Binary Converter shows the same UTF-8 bytes in binary or hex.