Base64 Encoder Decoder

🔐 What is Base64 Encoding?

Base64 is a binary-to-text encoding scheme that converts binary data (images, files, raw bytes) into ASCII text using 64 printable characters: uppercase letters (A-Z), lowercase letters (a-z), digits (0-9), plus (+), and slash (/). A 65th character (=) serves as padding.

How it works: Base64 groups input data into chunks of 3 bytes (24 bits), then splits those 24 bits into four 6-bit groups. Each 6-bit group represents a number 0-63, which maps to one of the 64 Base64 characters. For example, the text “Hello” (5 bytes) becomes “SGVsbG8=” (8 Base64 characters).

Why 33% larger? Because Base64 uses 4 characters to represent 3 bytes, encoded output is always approximately 33.33% larger than the original. The trade-off: text-safety. Base64 output contains only ASCII characters safe for transmission through email, JSON, XML, URLs, and other text-based protocols that may corrupt binary data.

Padding: If input bytes aren’t perfectly divisible by 3, Base64 adds padding (=) characters to make output length a multiple of 4. “Hello” (5 bytes = not divisible by 3) requires 1 padding character: “SGVsbG8=”.

⚡ Instant Encoding & Decoding

This tool provides real-time Base64 conversion entirely in your browser with zero latency. No server round-trips, no network delays, no data uploads.

Encode mode: Type or paste text in the input field—output appears instantly as you type. For files, click “Upload File” to encode images (PNG, JPG, GIF, SVG), PDFs, documents, audio, or any binary file up to 10MB. Files are encoded as data URIs (e.g., data:image/png;base64,iVBORw0KG...) suitable for embedding in HTML, CSS, JSON, or database storage.

Decode mode: Paste Base64 string—decoded text appears instantly. The tool auto-detects valid Base64 format and displays a green “Valid Base64 detected” badge. For Base64-encoded images, automatic preview displays below output. For other files (PDFs, audio), click “Download Decoded File” to save to your device.

Swap functionality: Quickly chain operations by clicking the swap button (⇅) to move output to input and toggle between encode/decode modes. Useful for testing round-trip integrity (encode → decode → verify original) or multi-step transformations.

🌐 URL-Safe Base64 Support

Standard Base64 uses characters (+, /, =) that have special meaning in URLs, causing parsing errors when embedded in query parameters or path segments. URL-safe Base64 (RFC 4648 Section 5) solves this by replacing problematic characters.

Substitutions: Plus (+) becomes hyphen (-), slash (/) becomes underscore (_), and padding (=) is removed or replaced with ~ (tilde). For example, standard Base64 a+b/c== becomes URL-safe a-b_c or a-b_c~~.

When to use URL-safe encoding:

• Embedding Base64 in URL query parameters: ?token=abc123-_xyz
• Using Base64 in URL path segments: /api/data/abc123-_xyz
• Storing Base64 in filenames: file_abc123-_xyz.txt
• Including Base64 in HTTP headers or cookies
• Generating short URLs or permalink identifiers

Automatic detection: This tool’s decode mode automatically detects both standard and URL-safe Base64 formats. Enable the “URL-safe Base64” checkbox when encoding to ensure output uses hyphen/underscore substitutions.

📁 File Encoding & Image Preview

Upload any file type to convert to Base64 data URI format for direct embedding in code, APIs, or databases.

Supported file types: Images (PNG, JPEG, GIF, SVG, WebP, BMP), documents (PDF, TXT, DOCX), audio (MP3, WAV, OGG), video (MP4, WEBM), archives (ZIP, TAR), and any binary format. 10MB file size limit ensures browser performance remains responsive.

Data URI format: Encoded files use data URI scheme: data:[MIME type];base64,[Base64 data]. For example, PNG image becomes data:image/png;base64,iVBORw0KGgoAAAANSU.... This format is directly usable in:

• HTML: <img src="data:image/png;base64,..."> (no external HTTP request)
• CSS: background-image: url(data:image/png;base64,...) (inline backgrounds)
• JSON APIs: {"image": "data:image/png;base64,..."} (file attachments)
• Canvas/WebGL: Direct data URI to canvas or texture loading

Image preview: When decoding Base64 images, the tool automatically detects image MIME types (image/png, image/jpeg, etc.) and displays a preview below the output text. This is useful for extracting images from JSON responses, database fields, or HTML source code. Click “Download Decoded File” to save the image to your device with correct file extension.

Use cases:

• Embed small icons/logos directly in HTML to reduce HTTP requests
• Store user profile pictures in database as text (no file storage needed)
• Send file attachments in REST API JSON payloads
• Include charts/graphs in email HTML templates
• Serialize binary data for localStorage or cookies

🔧 Encoding Options & Character Sets

UTF-8 (recommended): Default encoding for modern applications. Handles all Unicode characters including emoji (😀), accented letters (café), and non-Latin scripts (日本語, العربية). UTF-8 uses 1-4 bytes per character, making it efficient for most text. Always use UTF-8 unless integrating with legacy systems requiring specific encodings.

ASCII: Only supports characters 0-127 (basic English alphabet, digits, punctuation). Fails on special characters, emoji, or non-English text. Use only for pure ASCII data or legacy system compatibility. Attempting to encode Unicode characters with ASCII encoding will corrupt data.

UTF-16: Uses 2 or 4 bytes per character. Primarily used by Windows internals and some legacy Java systems. For most web applications, UTF-16 doubles file size unnecessarily—stick with UTF-8. Choose UTF-16 only when explicitly required by target system API documentation.

Encoding mismatch errors: If decoded output shows garbled characters (�), the original encoding likely wasn’t UTF-8. Try decoding with different encoding assumptions or check source data documentation. Common issue: decoding UTF-8 encoded Base64 as ASCII (or vice versa) corrupts non-ASCII characters.

💾 Local Storage & Privacy

This tool runs entirely client-side in your browser with zero server communication. All processing happens using JavaScript native APIs (btoa, atob, FileReader, TextEncoder, TextDecoder).

Privacy guarantees:

• No data uploads to servers—files and text never leave your device
• No cookies, no analytics, no tracking pixels
• No external API calls or third-party service dependencies
• All operations occur in isolated browser sandbox with Content Security Policy enforcement

State persistence: The tool automatically saves your current state (mode, input, output, settings) to browser localStorage for convenience. Refresh the page and resume where you left off. This is purely local storage—no cloud sync or external access. Clear browser data to remove saved state.

Offline capability: Save this page to your device and use completely offline. All functionality works without internet connection since there are no external dependencies. Useful for secure environments, air-gapped systems, or situations requiring guaranteed data privacy.

Verification: Open browser DevTools (F12) → Network tab → perform encoding/decoding → zero network requests appear (except initial page load). This confirms all processing is client-side.

📊 Data Size & Performance

Size overhead: Base64 encoding increases data size by exactly 33.33% (4:3 ratio). For example:

• 3 KB original → 4 KB Base64 (1 KB overhead)
• 1 MB original → 1.33 MB Base64 (333 KB overhead)
• 10 MB original → 13.33 MB Base64 (3.33 MB overhead)

Performance considerations:

• Text encoding/decoding: Instant for <1MB, <100ms for 1-10MB
• File upload encoding: ~500ms per MB (varies by device)
• Large file warning: Browser memory limits ~100MB total, 10MB input limit for safety
• Mobile devices: Slower processing on older phones, reduce file sizes if laggy

Optimization tips:

• Compress files before Base64 encoding (e.g., use PNG optimization for images)
• For large data transfers, use binary protocols (WebSocket, HTTP multipart) instead of Base64 in JSON
• Split large files into chunks and encode separately for progress indicators
• Consider gzip compression after Base64 encoding for HTTP transmission (reduces overhead)

🎯 Common Use Cases

1. Email Attachments (MIME) Email protocols transmit text-only. Binary attachments (PDFs, images, ZIP files) must be Base64-encoded in MIME parts. Email clients automatically encode attachments when sending and decode when receiving. If manually constructing email MIME messages (e.g., via SMTP API), encode attachments with this tool and embed in Content-Transfer-Encoding: base64 sections.

2. Embedding Images in HTML/CSS Eliminate external HTTP requests by embedding small images directly as data URIs. Encode icon, logo, or background image to Base64, then use: <img src="data:image/png;base64,[encoded data]"> or background-image: url(data:image/png;base64,[encoded data]). Best for images <10KB. Larger images increase HTML file size and slow initial page load. Trade-off: eliminates HTTP request overhead vs. larger HTML payload.

3. JSON API File Transfers REST APIs using JSON can’t transmit raw binary. Encode files to Base64 and include in JSON payload: {"filename": "report.pdf", "data": "JVBERi0xLjQ..."}. Receiving end decodes Base64 back to binary file. Alternative: use multipart/form-data for efficiency (no 33% overhead), but Base64-in-JSON is simpler for small files and supports all HTTP clients without multipart parsing.

4. HTTP Basic Authentication HTTP Basic Auth encodes credentials as Base64 in the Authorization header: Authorization: Basic [Base64(username:password)]. For example, username “user” + password “pass” → “user:pass” → Base64 “dXNlcjpwYXNz” → header Authorization: Basic dXNlcjpwYXNz. Warning: Base64 is not encryption! Always use HTTPS to protect Basic Auth credentials in transit. Base64 merely formats credentials for HTTP header compatibility.

5. Browser LocalStorage/Cookies LocalStorage and cookies only store text strings. To store binary data (images, serialized objects with binary), Base64-encode before storage. For example, save user profile picture: localStorage.setItem('avatar', 'data:image/png;base64,iVBORw...'). Retrieve and decode to display. Caveat: LocalStorage typically limits ~5-10MB per origin, and Base64 overhead reduces effective binary storage to ~3.5-7.5MB.

6. Cryptographic Keys & Certificates SSL/TLS certificates, RSA public keys, and AES encryption keys are binary. For storage in config files, transmission via JSON APIs, or display in UI, encode to Base64. Standard formats: PEM certificates wrap Base64-encoded certificate data with headers (-----BEGIN CERTIFICATE-----). This tool decodes PEM Base64 sections (strip headers first) or encodes raw binary keys to Base64 for embedding in JSON configuration.

7. QR Code Generation QR code libraries expect text input. To encode binary files (vCard, WiFi config, app data) in QR codes, Base64-encode the binary data first, then generate QR code from Base64 string. Scanning app decodes QR → Base64 string → decodes Base64 → original binary data. For URLs in QR codes, use URL-safe Base64 to avoid scanning errors from special characters.

🚨 Common Pitfalls & Troubleshooting

Pitfall 1: Treating Base64 as encryption Base64 is encoding (format transformation), not encryption (security). Encoding passwords or secrets with Base64 provides zero protection—anyone can decode instantly. Solution: Use proper encryption (AES-256, RSA) for confidential data, HTTPS for transmission, and hashing (bcrypt, SHA-256) for passwords.

Pitfall 2: Ignoring 33% size overhead Embedding large files as Base64 in JSON APIs or HTML increases payload size by 33%, slowing network transfer and increasing bandwidth costs. Solution: Use Base64 only for small files (<100KB). For larger files, use binary protocols (HTTP multipart, WebSocket binary frames) or cloud storage URLs.

Pitfall 3: Standard Base64 in URLs Using standard Base64 (with +, /, =) in URL query parameters or path segments breaks URLs. For example, ?token=abc+def/ghi== is parsed as abc def/ghi (+ becomes space). Solution: Always use URL-safe Base64 for URL contexts—enable the “URL-safe” checkbox in this tool.

Pitfall 4: Encoding mismatch (UTF-8 vs ASCII) Encoding Unicode text with ASCII, then decoding as UTF-8 (or vice versa) corrupts characters. For example, “café” ASCII-encoded → invalid bytes → UTF-8 decode → “café”. Solution: Always use UTF-8 for text encoding unless you have specific legacy system requirements.

Pitfall 5: Missing padding characters Some Base64 implementations omit padding (=) characters. Standard Base64 requires padding to make output length a multiple of 4. Decoding unpadded Base64 may fail in strict parsers. Solution: This tool handles both padded and unpadded Base64 automatically. When generating Base64 for external systems, check their requirements—add padding if needed.

Pitfall 6: Line breaks in Base64 strings MIME and PEM standards insert line breaks every 64-76 characters for readability. Many Base64 decoders reject line breaks. For example, PEM certificates have breaks after 64 chars. Solution: Remove all whitespace (spaces, line breaks, tabs) before decoding. This tool auto-strips whitespace, but be aware when manually copying Base64 from formatted sources.

🔍 Base64 Character Set Reference

Base64 uses 64 characters plus padding:

Characters 0-25: A-Z (uppercase letters) Characters 26-51: a-z (lowercase letters) Characters 52-61: 0-9 (digits) Character 62: + (plus) | - (hyphen in URL-safe) Character 63: / (slash) | _ (underscore in URL-safe) Padding: = (equals) | omitted or ~ in URL-safe

Encoding table example:

• Value 0 → A
• Value 25 → Z
• Value 26 → a
• Value 51 → z
• Value 52 → 0
• Value 61 → 9
• Value 62 → +
• Value 63 → /

Binary to Base64 example: Text “Hi” → ASCII bytes [72, 105] → Binary [01001000 01101001] → Group into 6-bit [010010 000110 1001XX] → Pad with zeros [010010 000110 100100] → Base64 values [18, 6, 36] → Characters [S, G, k] → Add padding for 4-char length: “SGk=”