Paste Base64 strings below. Separate multiple images with blank lines. Supports Data URL prefix (data:image/png;base64,...) or raw Base64.
Import text files containing Base64 strings. Each file should have images separated by blank lines.
Select an image from the gallery to preview and download
No images converted yet. Paste Base64 text or import text files to get started.
The internet was originally designed for 7 bit ASCII text transmission. Email systems like SMTP (Simple Mail Transfer Protocol) could only handle textual data reliably. Binary files such as images, executables, or archives would become corrupted when sent through these systems because control characters or high-bit bytes (values above 127) would be misinterpreted, altered, or stripped by mail transfer agents. A solution was needed to represent arbitrary binary data using only the safe, printable ASCII characters. [RFC 821, SMTP]
Base64 encoding was first formally described in RFC 989 (1987) for the Privacy Enhanced Mail (PEM) protocol, which required a way to encode binary cryptographic keys and certificates into ASCII for secure email transmission. The encoding scheme took three 8 bit bytes (24 bits) and split them into four 6 bit groups, each mapped to a character in a set of 64 characters (A-Z, a-z, 0-9, +, /) with '=' used for padding. This design ensured that encoded data remained safe for transmission through 7 bit systems and could be easily decoded. [RFC 989, PEM]
Base64 was adopted as the standard encoding for MIME (Multipurpose Internet Mail Extensions) in RFC 1341 (1992) and later RFC 2045 (1996). MIME extended email capabilities to support non ASCII text, attachments, images, audio, and video. Base64 became the primary encoding for binary attachments, enabling email clients worldwide to send and receive photos, documents, and other files. This standardization cemented Base64 as a fundamental internet technology, still used in modern email systems. [RFC 2045, MIME]
Beyond email, Base64 is now ubiquitous across web technologies. Data URLs (RFC 2397, 1998) allow embedding images directly in HTML and CSS. JSON Web Tokens (JWT, 2015) encode claims in Base64. REST APIs transmit binary files as Base64 strings. The encoding appears in XML, JSON, HTML forms, and countless other specifications. Despite a 33 percent size overhead, the simplicity and universal compatibility of Base64 ensure its continued relevance. [RFC 2397, Data URLs] [RFC 7519, JWT]
Base64 converts binary data (8 bit bytes) into a string of 64 safe ASCII characters. The character set includes A-Z (26 characters), a-z (26 characters), 0-9 (10 characters), plus '+' and '/' (2 characters), totaling 64. Each Base64 character represents 6 bits of data (since 2^6 = 64). The encoding process groups binary data into chunks of 24 bits (three bytes) and splits them into four 6 bit groups, each mapped to a Base64 character. This 3 to 4 ratio is why encoded data is approximately 33 percent larger than the original. [Wikipedia, Base64]
Consider the ASCII text "Man" which has byte values: 'M' (77), 'a' (97), 'n' (110). In binary: 01001101, 01100001, 01101110. Concatenated: 010011010110000101101110 (24 bits). Split into 6 bit groups: 010011 (19), 010110 (22), 000101 (5), 101110 (46). Map to Base64 table: 19->T, 22->W, 5->F, 46->u. Result: "TWFu". The original "Man" (3 bytes) becomes "TWFu" (4 characters).
When input data length is not a multiple of 3 bytes, padding is added to reach a full 24-bit block. For 1 byte (8 bits), two padding characters '=' are added: 8 bits -> two 6 bit groups (12 bits) plus two '=' characters. For 2 bytes (16 bits), one '=' is added: 16 bits -> three 6 bit groups (18 bits) plus one '='. Decoders use '=' padding to determine the original data length. This padding ensures that Base64 strings always have a length divisible by 4, simplifying parsing and validation. [RFC 4648, Base64]
Data URLs (RFC 2397) embed resources directly in web pages using the format: data:[
This converter operates entirely in your browser. No Base64 strings or images are ever sent to a server. All processing happens locally using JavaScript APIs. This ensures privacy and speed, as your data never leaves your device. The tool works offline once loaded, making it suitable for secure or air gapped environments. [MDN, FileReader API]
The tool first scans input text for Base64 patterns using regular expressions. It identifies strings that match the Base64 character set (A-Za-z0-9+/=) with appropriate length thresholds. For Data URLs, it recognizes the "data:image/" prefix and extracts the Base64 portion. Empty lines serve as image separators, allowing batch processing of multiple images from a single text block. Each detected string is normalized to a complete Data URL if needed, then passed to the decoding engine.
For each Base64 string, the tool creates an HTMLImageElement and sets its src attribute to the Data URL. The browser's native image decoder processes the Base64 data, loading the image asynchronously. Once loaded (onload event), the image dimensions (width and height) are captured. The tool then draws the image onto an offscreen HTMLCanvasElement using the canvas rendering context's drawImage() method. This canvas can later export the image in various formats using toBlob() or toDataURL() methods.
Converted images are stored as JavaScript objects containing the Data URL, original filename, dimensions, and format. The gallery displays thumbnails created by setting small image elements' src attributes. The preview panel uses canvas rendering to scale images proportionally for display (max 600x400). For downloads, the canvas toBlob() method exports images to PNG, JPEG, or WebP formats with configurable quality (JPEG 0.92). The ZIP archive feature uses JSZip library to package all images without server interaction, creating a downloadable archive entirely client side. [JSZip Documentation]
Base64 remains the standard encoding for email attachments. When you send an image via email, your email client automatically Base64 encodes the binary file and inserts it into the MIME structure. The recipient's client decodes it back to binary. This ensures the attachment survives transmission through email servers that might otherwise modify binary data. Most modern email systems also support quoted printable for text heavy content, but Base64 is preferred for binary files. [Wikipedia, MIME]
Web developers embed small images directly in HTML, CSS, or JSON using Data URLs. This reduces HTTP requests for tiny assets like icons, spinners, or UI elements. For example, '<img src="data:image/png;base64,...">' loads the image without a separate network request. CSS can similarly use background-image: url("data:..."). This technique is valuable for self contained demos, email signatures, or offline applications. However, Base64 images are not cached separately and increase document size, so they are best for assets under a few kilobytes.
JWT, defined in RFC 7519, encodes authentication claims as three Base64Url safe parts: header, payload, and signature. Base64Url is a variant replacing '+' with '-' and '/' with '_' and omitting '=' padding for URL safety. JWTs are stateless authentication tokens used in OAuth, OpenID Connect, and modern web APIs. The Base64 encoding ensures that tokens contain only URL safe characters, making them easy to transmit in HTTP headers, cookies, or query strings. [JWT.io]
The primary limitation of Base64 is size expansion. Encoding increases data size by approximately 33 percent (4 bytes output per 3 bytes input). For large files, this overhead is significant. Additionally, Base64 provides no encryption or compression; it only converts format. Decoding invalid or malformed Base64 strings may produce errors or corrupted output. Some variants use different character sets (Base64URL, XML-compatible Base64) for specific environments. For large binary transfers, modern alternatives like HTTP binary uploads or WebSockets are more efficient, but Base64 remains essential for text only contexts. [Wikipedia, Base64 Applications]