Base64 maps every 3 bytes of input to 4 characters drawn from A-Z, a-z, 0-9, + and /, so binary-unsafe channels (JSON strings, HTTP headers, data URIs) can carry arbitrary bytes. This encoder runs your text through TextEncoder before btoa, which means multibyte UTF-8 input like accented characters or CJK encodes correctly instead of throwing the 'characters outside of the Latin1 range' error a bare btoa call produces.
The 4/3 rule and what padding means
Output length is always a multiple of 4: every full 3-byte group becomes 4 characters, and a leftover 1 or 2 bytes are padded out with = signs. 'M' encodes to TQ== (two pads), 'Ma' to TWE= (one pad), 'Mar' to TWFy (none). The padding carries no data; it only signals how many bytes the final group held.
The same arithmetic sets the size cost: 3,000 bytes become exactly 4,000 characters, and a 1 MiB file (1,048,576 bytes) becomes 1,398,104 characters, roughly 33% overhead before any transport compression. That overhead is the standard argument against inlining large images as data URIs when a plain file reference would do.
Standard base64 vs base64url
This tool speaks strict standard base64. The URL-safe variant (RFC 4648 section 5) swaps + for - and / for _ so the output survives inside URLs and filenames, and usually drops the = padding too. JWT segments use it, which is why pasting a token segment containing - or _ here fails with 'Invalid Base64'. To decode one anyway, replace - with + and _ with / first. Missing padding alone is fine: the decoder is forgiving about that, so SGVsbG8 (no trailing =) still decodes to Hello.
Questions people ask
Why does a base64 string that other tools accept fail here with 'Invalid Base64'?
Two distinct causes share that message. Either the string contains base64url characters (- or _), or it decodes fine as bytes but those bytes are not valid UTF-8 text. This tool's decoder runs the output through a strict UTF-8 check, so base64 of an image, a gzip blob, or any binary payload is rejected even though the base64 itself is well-formed. Binary payloads belong in the file-to-base64 and base64-to-PDF tools instead.
Does base64 protect the content in any way?
No. There is no key and no secret; decoding is a fixed, instant transformation anyone can apply. Treat base64 in a config file as plain text with extra steps. If you need actual confidentiality, encrypt with the AES tool and then base64 the ciphertext for transport.
The JWT decoder handles the base64url variant automatically, and the hex encoder is the alternative byte-to-text encoding when you'd rather trade 100% overhead for human-readable byte boundaries.