Encode text to Base64 or unpack a Base64 string into plain characters, with full Unicode handling and a live encoding-overhead readout.
Base64 exists because a great deal of plumbing still assumes text. Email headers, JSON string fields, data URIs and HTTP authorization headers all need arbitrary bytes expressed in an alphabet of 64 characters that survives the journey. The Text to Base64 Converter runs that conversion in both directions, going through UTF-8 so accented and CJK characters return intact rather than breaking on a byte boundary.
Encoding consumes three bytes and emits four characters, which is the whole source of the familiar 33% growth. A stat row beneath the panes measures it against your actual input and reads Input: 24 chars, Output: 32 chars, Overhead: +33%. Watch that figure with multibyte text: 24 Greek letters occupy 48 bytes and encode to 64 characters, and since the overhead compares characters rather than bytes it reports +167% there.
Decoding strips all whitespace before parsing, so a blob an email client wrapped at 76 columns decodes without you rejoining the lines by hand. Encoding and decoding both happen on the page, with no request leaving the tab.
HTTP basic auth wants a user:password pair encoded. Type svc-deploy:Rk7#pQ2m into Plain Text Inputand Base64 Output returns c3ZjLWRlcGxveTpSazcjcFEybQ==, which is exactly the string that follows Authorization: Basic in a request header. The trailing == is padding rather than data: the credential is 19 bytes, 19 leaves a remainder against 3, so the final group is filled out to four characters.
+ and /. That is not URL-safe, so a token going into a query string needs those two characters substituted before use.Invalid Base64 string. Ensure the input is valid Base64-encoded text. Missing padding is the most common trigger.