Text to Base64 Converter

A text to Base64 converter rewrites text as a string drawn from 64 printable ASCII characters, so it can travel through channels built for plain text: email bodies, HTTP headers, JSON strings, and URLs. Base64 is defined in RFC 4648. It is an encoding, not encryption: decoding needs no key, so it hides nothing.

Text becomes bytes before it becomes Base64, and the character encoding decides which bytes. UTF-8, the default, covers every Unicode character and spends 1 byte on an ASCII letter, 2 on most accented Latin letters, 3 on most CJK ideographs, and 4 on most emoji. ASCII covers only code points 0 to 127 and ISO-8859-1 covers 0 to 255, one byte per character; a character outside the chosen range is encoded as a question mark (byte 3F) and listed beside the result. The same choice applies when decoding, so Base64 made from ISO-8859-1 text needs ISO-8859-1 to read back correctly.

The encoder takes the bytes three at a time, splits each 24-bit group into four 6-bit values, and maps each value to the alphabet A to Z (0 to 25), a to z (26 to 51), 0 to 9 (52 to 61), + (62), and / (63). A final group of one byte becomes two characters plus ==, and a final group of two bytes becomes three characters plus =, so the output is 4 characters for every 3 bytes, rounded up: about a third larger than the input. The URL-safe alphabet from section 5 of RFC 4648 replaces + with - and / with _, the two characters that collide with URL and filename syntax, and in that mode the trailing = padding is dropped, as JSON Web Tokens do. Settings holds the character encoding, the URL-safe variant, and line wrapping at 76 characters, the limit RFC 2045 sets for Base64 in email bodies (PEM certificate files wrap at 64 under RFC 7468).

Decoding reverses the steps and accepts either alphabet, with or without padding, and ignores line breaks. A result that does not form valid UTF-8 is flagged: it usually means the Base64 holds binary data such as an image, a compressed file, or a DER certificate, or text in another encoding. The converter reads text typed or pasted into the page, not files, so binary content cannot be encoded here. Encoded length counts output characters without line breaks; decoded length counts characters as a reader sees them, one per emoji.

The text Hi! is the bytes 48 69 21, or 01001000 01101001 00100001 in binary. Regrouped into 6-bit values that is 18, 6, 36, and 33, the characters S, G, k, and h, so Hi! encodes to SGkh with no padding. A lone é is the two UTF-8 bytes C3 A9: 11000011 10101001 regroups into 110000, 111010, and 1001 padded with two zero bits to 100100, which are 48, 58, and 36, or w, 6, and k, and the missing third byte adds one = for w6k=. In ISO-8859-1 the same é is the single byte E9, which encodes to 6Q==.

Base64 turns up wherever text-only channels carry data, from web pages to authentication headers to configuration stores. The scenarios below all start from text, which is what this converter accepts.

• Web Development: An SVG icon is plain XML text, so its Base64 form can sit inside a CSS background-image or an HTML image source as a data URI beginning data:image/svg+xml;base64, saving a separate request for a small graphic.
• API Integration: HTTP Basic authentication (RFC 7617) sends the username and password joined by a colon and Base64-encoded in the Authorization header. The pair user:pass becomes dXNlcjpwYXNz, and decoding a captured header recovers the password just as directly, which is why Basic authentication is only safe over HTTPS.
• Email Systems: Text parts of a MIME message can declare Content-Transfer-Encoding: base64 with lines of at most 76 characters; the line-wrapping option produces that layout for a hand-built message or a test fixture.
• Configuration Files: Values that would clash with YAML or JSON quoting rules, such as tokens with special characters or multi-line text, can be stored as one Base64 string and decoded by the application at startup.
• Data Debugging: Base64 strings in log files, cookies, and the header and payload segments of a JSON Web Token decode back to readable JSON. A JWT header such as eyJhbGciOiJIUzI1NiJ9 uses the URL-safe alphabet without padding and decodes as is to {"alg":"HS256"}.
• Character Encoding Checks: Encoding the same word under UTF-8 and ISO-8859-1 shows how the byte sequences differ (é gives w6k= in one and 6Q== in the other), which explains the garbled text that appears when a system reads one encoding as the other.
• Security Review: Obfuscated commands in scripts, macros, and URLs are often Base64; decoding them shows the hidden command or address without running anything. A payload that decodes with a UTF-8 warning is binary and belongs in a hex viewer instead.
• Database Storage: Text with characters that a legacy column or export format mangles, such as emoji in a Latin-1 table, survives the trip as a Base64 string and decodes back to the exact original.