Advanced Base64 Encoder.

Base64 encoding is a method of representing arbitrary binary data — images, audio files, cryptographic keys, or raw byte streams — as a sequence of printable ASCII characters. Binary protocols and filesystems can handle raw bytes natively, but many text-based transport layers cannot. Email (MIME), JSON payloads, CSS data URIs, and HTTP Basic Authentication headers all operate over text channels that would misinterpret raw binary control characters. Base64 solves this by mapping every 3 bytes of binary input to 4 printable characters drawn from a 64-character alphabet (A–Z, a–z, 0–9, +, /), producing a universally safe string that survives any text pipeline. It is the dominant encoding for embedding images in HTML or CSS, serialising binary blobs inside JSON APIs, and transmitting file attachments over SMTP.

Standard Base64 uses the characters + (plus) and / (slash) as its 62nd and 63rd alphabet characters, and pads output to a multiple of 4 characters with = (equals) signs. This works perfectly for file storage or email, but breaks URL query strings and path segments: + is interpreted as a space in URL-encoded form data, / is the path delimiter, and = confuses routing parsers. Base64URL (defined in RFC 4648 §5) makes the encoding web-safe by replacing + with - (hyphen) and / with _ (underscore), and by making padding optional. This variant is the mandatory encoding for JWT headers and payloads, OAuth 2.0 PKCE code challenges, and any Base64 value that must survive inside a URL query parameter or HTTP header without percent-encoding.

Base64 encodes data in 3-byte (24-bit) blocks, mapping each block to exactly 4 output characters. When your input length is not a multiple of 3, the final block is short: one leftover byte produces two Base64 characters plus two = padding characters; two leftover bytes produce three Base64 characters plus one = padding character. The padding exists to keep the output length a strict multiple of 4, which allows decoders to determine the exact byte count of the original data without needing an out-of-band length field. Trailing = signs are therefore not part of your data — they are structural padding. Base64URL encoding makes this padding optional, which is why JWT tokens often have no trailing equals signs.

No. Base64 is purely an encoding scheme — a reversible, deterministic mapping between bytes and printable characters. It provides zero confidentiality. Any person or system with access to a Base64 string can decode it back to the original data instantly without any key, password, or secret. This is a critical security distinction: if you Base64-encode a password, API key, or private token and transmit it in a header or embed it in client-side JavaScript, it is effectively in plaintext. For confidentiality, you need cryptographic encryption (AES-GCM, ChaCha20-Poly1305) or, for passwords, a one-way hashing function (bcrypt, Argon2). Base64 is used alongside encryption for transport compatibility — for example, an AES-encrypted ciphertext is often Base64-encoded before being embedded in a JSON field — but the encoding itself adds no security.

Yes — this is precisely what the client-side FileReader API enables. When you drag and drop an image or click to select a file, your browser passes a reference to that file directly to the JavaScript FileReader.readAsDataURL() method running inside the page. The browser reads the raw file bytes from your local disk, encodes them as Base64, and prefixes the result with the correct MIME type to form a complete Data URI (e.g., data:image/png;base64,iVBOR…). This entire process happens inside your browser's local sandbox. The file bytes never touch a network socket, are never sent to a server, and are never logged. The resulting Data URI can be pasted directly into an img src attribute, a CSS background-image property, or a JSON payload — a technique used for embedding assets into single-file HTML documents, email templates, and offline-capable web apps.

To convert a JSON object to a Base64 string for use in an Authorization header or API parameter, first serialise your JSON with JSON.stringify() to get a compact UTF-8 string, then pass that string through a Base64 encoder. In JavaScript this is btoa(unescape(encodeURIComponent(jsonString))) or, for modern runtimes, Buffer.from(jsonString).toString("base64"). Paste your raw JSON into this tool's input panel with Encode mode active — it handles the UTF-8 byte conversion correctly and produces the output string. If the header is a URL parameter or a JWT component, switch to Base64URL mode to replace + and / characters with their web-safe equivalents. The reverse — decoding a Base64-encoded API response back to readable JSON — works by pasting the encoded string with Decode mode active.