Base64 Hub

Encode and decode Base64 for text strings and images.

TextBase64

Text to Encode

Deep-Dive Technical Documentation

RFC 4648: The Formal Base64 Specification

Base64 encoding is formally defined in RFC 4648 (published October 2006, superseding RFC 3548). The standard specifies a 65-character alphabet: A–Z (indices 0–25), a–z (26–51), 0–9 (52–61), '+' (62), '/' (63), and '=' as the padding character. The encoding process works on 24-bit groups: it reads three input octets (3 × 8 = 24 bits), splits them into four 6-bit values, and maps each 6-bit value to the corresponding alphabet character. When the input length is not a multiple of three, the encoder pads the final group with zero bits and appends one or two '=' characters to signal the padding to the decoder. RFC 4648 also defines Base64url — a URL-safe variant that replaces '+' with '-' and '/' with '_' — which is the encoding used inside JWTs, OAuth tokens, and any context where the standard alphabet would collide with URI reserved characters. Base64 Hub implements both variants, automatically detecting the alphabet when decoding and letting you choose the variant when encoding.

The 6-Bit Mapping Pipeline: How Bytes Become Characters

Understanding Base64 at the bit level removes all the mystery. Take three ASCII bytes — say, 'Man' — which are 77, 97, 110 in decimal, or 01001101 01100001 01101110 in binary. Concatenate the 24 bits and re-split into four 6-bit chunks: 010011 010110 000101 101110. Map each chunk to the Base64 alphabet: index 19 = 'T', index 22 = 'W', index 5 = 'F', index 46 = 'u'. So 'Man' becomes 'TWFu'. This 3-to-4 byte expansion means Base64 always inflates the data by exactly 33% (plus up to 2 padding bytes). In the browser, the btoa() function performs this mapping natively — but it only handles Latin-1 characters (code points 0–255). For full Unicode support (emoji, CJK, Arabic), you must first encode the string to UTF-8 bytes using TextEncoder or the encodeURIComponent/unescape trick, then pass those bytes to btoa(). Base64 Hub handles this transparently so you never hit the 'character out of range' error that catches developers off guard.

Data URIs and the Inline Embedding Pattern

One of the most practical applications of Base64 is the Data URI scheme (RFC 2397), which lets you embed file content directly into HTML, CSS, or JSON without a separate HTTP request. The format is data:[mediatype][;base64],<data> — for example, data:image/png;base64,iVBORw0KGgo... embeds a PNG image inline. This eliminates a network round-trip, which is valuable for small assets like icons, SVG logos, or font subsets where the HTTP overhead would exceed the payload itself. The trade-off is the 33% size inflation: a 30 KB image becomes roughly 40 KB as a Base64 Data URI, plus the browser must decode it before rendering. The general rule of thumb is to inline assets under 10 KB and serve anything larger as a separate file. CSS background-image properties, HTML img src attributes, and even JSON API payloads for avatar thumbnails all commonly use this pattern. Base64 Hub's image mode generates Data URIs automatically from dropped or selected files.

Base64 in Authentication and Token Architectures

Base64 appears at almost every layer of modern authentication. HTTP Basic Auth concatenates username:password and Base64-encodes the result into the Authorization header (RFC 7617). JSON Web Tokens (JWTs) are three Base64url-encoded segments separated by dots: the header (algorithm and type), the payload (claims like sub, exp, iat), and the signature. OAuth 2.0 client credentials are often Base64-encoded in the Authorization header when requesting tokens from the token endpoint. SAML assertions use standard Base64 to encode XML documents within HTTP POST bindings. A critical point that trips up developers: Base64 is not encryption. It is a reversible encoding with zero secrecy — anyone can decode a JWT payload without a key. The signature segment provides integrity (proof that the payload hasn't been tampered with), but the payload itself is readable to anyone. Base64 Hub is useful here for quickly decoding a JWT payload during debugging, inspecting SAML assertions, or verifying that a Basic Auth header contains the expected credentials.

What is Base64 Hub?

Base64 Hub handles the encoding and decoding you do ten times a week but never want to write a script for. Base64 is the binary-to-text scheme from RFC 4648 — it takes every 3 bytes of input (24 bits), chops them into four 6-bit chunks, and maps each chunk to a printable ASCII character from a 64-character alphabet (A–Z, a–z, 0–9, +, /). Padding with '=' fills in when the input length doesn't divide evenly by three. That's the whole trick, and it's why you can shove an image into a JSON payload, stuff credentials into an HTTP Authorization header, or embed a favicon directly in your HTML without a separate file request. The tool gives you two modes. Text mode lets you encode any UTF-8 string to Base64 or decode Base64 back to readable text — handy when you're debugging HTTP Basic Auth headers, inspecting JWT payloads, or pulling apart SAML assertions. Image mode lets you drag in a PNG, JPEG, GIF, WebP, or SVG and instantly get a copy-paste-ready data URI (complete with MIME prefix) for inlining in your markup. You can also paste a raw Base64 string to preview it visually, which is a lifesaver when someone sends you an encoded image in a Slack thread and you need to see what it actually is. The trade-off you should know: Base64 inflates data by roughly 33% because every 3 bytes become 4 characters. For small icons under ~5 KB, that overhead is worth killing an HTTP round-trip. For anything bigger, serve the file from a CDN. All encoding and decoding runs in your browser via native btoa()/atob() — nothing hits a server.

How to Use

Select your workflow: 'Text' mode for encoding/decoding UTF-8 strings, or 'Image' mode for converting image files to and from Base64 data URIs.
In Text mode, paste your plaintext (or Base64 string) into the input area. Use the swap arrow to toggle between Encode and Decode directions, then click the action button to process.
In Image mode, click the upload area to select a PNG, JPEG, GIF, WebP, or SVG file. The tool reads the file via the browser's FileReader API and outputs the complete data URI including the MIME type prefix.
To decode an existing Base64 image string, paste it into the textarea in Image mode and click 'Preview Base64' to render it visually.
Click 'Copy' to place the encoded or decoded result on your clipboard, ready to embed in HTML, CSS, API headers, or configuration files.

Common Use Cases

Generating data URIs for embedding images directly in HTML <img> tags or CSS background-image properties, eliminating extra HTTP requests and improving page load performance.
Encoding HTTP Basic Authentication credentials ('username:password') into the Base64 format required by the Authorization header in REST API calls.
Inspecting and debugging JSON Web Tokens (JWTs) by decoding the Base64url-encoded header and payload segments to read claims like 'exp', 'sub', and 'iss'.
Converting binary file attachments (PDFs, images, ZIP archives) into Base64 strings for transmission through JSON or XML APIs that don't support multipart uploads.
Decoding Base64-encoded SAML assertions, OAuth tokens, or webhook payloads received from third-party identity providers and SaaS integrations.
Creating inline SVG or favicon data URIs for single-file HTML applications, email templates, or Progressive Web App manifests.
Encoding cryptographic hashes, HMAC signatures, or encryption keys into a safe printable format for storage in environment variables, config files, or databases.

Frequently Asked Questions

Take 3 bytes of input (24 bits), split them into four 6-bit groups, and look up each group in a 64-character alphabet (A–Z, a–z, 0–9, +, /). If the input isn't evenly divisible by 3, pad with one or two '=' characters. That's why Base64 output is always a multiple of 4 characters, and the result is exactly 4/3 the size of the original.

Nope. Base64 is encoding, not encryption. Anyone with a decoder can reverse it instantly. If you need actual security, encrypt first (AES-256, RSA, whatever fits your threat model), then Base64 the ciphertext if you need it in a text-safe format. Treating Base64 as protection is a rookie mistake that shows up in security audits constantly.

Standard Base64 uses '+' and '/' as its 62nd and 63rd characters, with '=' for padding. Base64url swaps those for '-' and '_' and usually drops the padding entirely. You'll see Base64url in JWTs, URL query params, and filenames — anywhere a '+', '/', or '=' would break the parser. This tool uses standard Base64 via the browser's btoa()/atob(), so keep that in mind if you're working with JWTs.

Every 3 bytes of real data become 4 ASCII characters. You're using 6 of every 8 bits for actual information — that's 75% efficiency, or 25% overhead. Once you factor in padding and optional line breaks (MIME-style), the real-world bloat is about 33–37%. That's the price you pay for being able to shove binary through text-only pipes like JSON, email, and HTTP headers.

For tiny assets like favicons or UI icons (under ~5 KB), data URIs actually help — you kill an HTTP round-trip and the size penalty is negligible. But for anything bigger, it backfires. The 33% size bloat, the fact that browsers can't cache a data URI separately from the HTML, and the massive Base64 string cluttering your markup all make it slower than just serving the image from a CDN. Rule of thumb: under 5 KB, inline it. Over 5 KB, link it.

JavaScript's btoa() chokes on anything outside Latin-1 (code points 0–255). To handle emoji, CJK, accented characters — basically anything real-world — the tool runs the string through encodeURIComponent() first (turning it into percent-encoded ASCII), then unescape() to get raw bytes, and finally btoa(). Decoding reverses it: atob() → escape() → decodeURIComponent(). It's a well-known workaround that guarantees lossless round-trips for any Unicode text.

Client-Side Sandbox Security Verification

Zero server transmission. All processing runs entirely within your browser's JavaScript sandbox using native browser-compiled APIs. 0% of your data payloads ever cross an external server boundary, origin log, or third-party endpoint.

Browser-native compilation. Operations like JSON.parse(), btoa()/atob(), encodeURIComponent(), and the Intl API are executed by the browser engine itself (V8, SpiderMonkey, or JavaScriptCore) — no WebAssembly payloads, no remote execution, no server-side eval.

Independently verifiable. Open your browser's DevTools > Network tab while using any tool. You will see zero outbound requests containing your data. This is a verifiable, auditable privacy architecture.