Free Base64 Encoder & Decoder - Encode Files, Images & Text Online

Base64 converts binary data (images, files) to text using 64 ASCII characters (A-Z, a-z, 0-9, +, /). Why needed: some systems only accept text (JSON, XML, email), HTTP headers and URLs require ASCII only, embeds binary data in text formats safely. How it works: groups 3 bytes (24 bits) into 4 Base64 characters (6 bits each), padding with = if input not divisible by 3, output is ~33% larger than original due to encoding overhead. Common uses: data URLs (data:image/png;base64,...), email attachments (MIME), JSON APIs (binary blobs), JWT tokens (encoded payloads). Alternatives: hexadecimal (more readable but 100% larger), URL-safe Base64 (replaces +/ with -_), Base85/ASCII85 (more efficient, less common). Base64 is standard for embedding binary in text formats - universal support, simple algorithm, reversible.

Data URL embeds entire file in URL string: data:[MIME type];base64,[encoded data]. Example: data:image/png;base64,iVBORw0KGgo... embeds PNG image. Usage in code: <img src="data:image/png;base64,..."> (HTML), background: url(data:image/svg+xml;base64,...) (CSS), fetch("data:application/json;base64,...") (JavaScript). Advantages: single-file HTML (no external dependencies), works offline (no HTTP requests), faster for tiny files (<2KB, eliminates HTTP overhead), atomic deployment (image + HTML always in sync). Disadvantages: 33% size increase from Base64, cannot cache separately (entire HTML/CSS re-downloaded on change), clutters code (huge strings), not suitable for large images (>10KB slow and bloated). Best practices: use for small icons (<2KB), inline SVG instead when possible (no Base64 overhead), external files for anything >10KB (better caching). Email HTML requires data URLs (no external resources).

Base64 encoding increases size by ~33% (4/3 ratio): 1KB file → 1.37KB Base64, 10KB image → 13.7KB Base64, 1MB file → 1.33MB Base64. Why: 3 bytes (24 bits) become 4 Base64 characters (32 bits), wastes 2 bits per character for text-safety. Additional overhead: MIME type prefix (data:image/png;base64,), newlines in formatted Base64 (increase size further, optional). Compression interaction: Base64 encoded files don't compress well with gzip (random-looking text), encode BEFORE compressing for better results, some APIs transmit Base64 with gzip reducing overhead. Size comparison: 10KB PNG → 13.7KB Base64 → ~11KB gzipped Base64, external 10KB PNG can be served as 8KB with gzip + good for caching. Rule: acceptable for <5KB files embedded, use external files for >10KB, consider inline SVG for vectors (no Base64 needed, gzips well). Break-even point: 1-2KB files where HTTP overhead > Base64 size increase.

Base64 string itself has no filename or type - need MIME type detection: Data URLs: include MIME type explicitly (data:image/png;base64,... → .png file), tool extracts MIME and sets extension automatically. Raw Base64: file type detected from Base64 header (magic bytes), PNG starts with iVBORw0KGgo (decoded: \x89PNG), JPEG starts with /9j/ (decoded: \xFF\xD8\xFF), PDF starts with JVBERi0 (decoded: %PDF-). Common MIME to extension mapping: image/png → .png, image/jpeg → .jpg, application/pdf → .pdf, text/plain → .txt. Ambiguous cases: generic application/octet-stream (unknown binary), tool prompts for extension, or defaults to .bin. Manual specification: provide filename with extension if known, overrides auto-detection. Downloaded files: browsers use Content-Type from data URL or detected MIME, defaults to original encoding filename if provided. Tool shows detected type for verification before download.

Base64 is NOT encryption - it is ENCODING (reversible transformation, no security). Anyone can decode Base64 instantly using free tools, provides zero confidentiality. Common misconception: hiding API keys in Base64 (completely insecure, easily decoded), assuming Base64 obfuscates sensitive data (does not). Why it seems "scrambled": random-looking characters (iVBORw0KGgo...) look encrypted to non-technical users, but any programmer recognizes Base64 immediately. Actual security requires: encryption (AES, RSA with secret keys), hashing for passwords (bcrypt, argon2, irreversible), TLS/HTTPS for transmission (prevents interception). When Base64 appears in security: JWT tokens (Base64-encoded but also signed/encrypted), HTTP Basic Auth (username:password in Base64, insecure without HTTPS), TLS certificates (Base64-wrapped but cryptographically signed). Never use Base64 for: hiding passwords/secrets, security through obscurity, any confidentiality requirement. Use Base64 for: data transport, embedding binary, text compatibility only - not security.

Alternatives to Base64 for different use cases: Inline SVG (vectors): embed SVG XML directly without Base64 (<svg>...</svg> in HTML/CSS), smaller than Base64, more readable/editable, gzips better. Best for: logos, icons. Hexadecimal: represents bytes as pairs of 0-9A-F (48656C6C6F = "Hello"), 100% larger than original (vs 33% for Base64), more readable for debug, used in color codes (#FF5733). Base85/ASCII85: more efficient encoding (80% overhead vs 33%), less common browser support, PDF uses ASCII85 internally. URL-safe Base64: replaces +/ with -_ (safe in URLs/filenames), otherwise identical, JWT tokens use this. MIME multipart: email standard for mixing text + attachments, more complex but efficient, HTTP multipart/form-data. External files: serve images as separate files (best caching, parallel downloads), CDN benefits (edge caching, compression), no size overhead. Buffer/Blob: modern JavaScript uses Blob objects directly (no encoding), File API for client-side binary, fetch() handles binary natively. Choose based on: Base64 for maximum compatibility and text-only contexts, external files for anything >5KB (performance), inline SVG for vectors (efficiency).