Base64 Text & File Encoder/Decoder

What is Base64

Base64 encodes binary data into 64 ASCII characters (A-Z, a-z, 0-9, +, /, = padding). It was designed to move binary data through text-only systems like email (SMTP) and JSON APIs. The output is about 33% larger than the input because every group of 3 bytes is translated into 4 printable characters.¹

How the 6-bit encoding works

The encoding treats the input as a stream of bytes, groups them into 24-bit sets of three octets, and then splits each set into four 6-bit values; each value becomes one character from a fixed 64-entry alphabet, so the output length is always a multiple of four characters unless the caller explicitly omits the padding.²

A short string shows the ratio directly. Encoding the text hello produces aGVsbG8=, five bytes turned into eight Base64 characters including the trailing padding character. Pasting that same string back into Decode mode returns hello exactly, which is the easiest way to confirm the round trip is lossless before trusting the tool with a larger payload.

Base64 is encoding, not encryption. Anyone can decode it with no key. It is commonly used for data URIs (data:image/png;base64,...), embedding certificates in PEM files, and passing binary blobs through JSON APIs that only accept strings. The equal sign padding ensures the length is always a multiple of 4. RFC 4648 recommends that decoders reject data containing characters outside the alphabet, but some specifications instead ignore those characters, so different tools can disagree on whether a given string is valid.²

Why decode or encode offline?

Online Base64 tools require you to paste text or upload files to a remote server. For JWT tokens, private keys, or internal config blobs, that is a security violation. The moment your data reaches a third-party server, you have lost control of it regardless of what the privacy policy claims.

CapyToolkit processes everything in your browser tab using native btoa() and atob(), so the conversion never touches the network.³ Disconnect from the internet after loading the page and the tool keeps working for text, files, and data URIs. If you handle production secrets, authentication tokens, or customer records, keeping the data inside the tab removes whole classes of accidental exposure that no privacy policy can fully prevent.

Encoding vs decoding

In encode mode, the tool converts your text to UTF-8 bytes first (using the browser's TextEncoder), then transforms those bytes to Base64 with btoa(). This two-step process is necessary because btoa() only handles Latin-1 characters natively.³ The UTF-8 step ensures Chinese, Arabic, Emoji, and other non-ASCII text encodes correctly.⁴

In decode mode, the tool strips whitespace and validates the Base64 string against the character set (/^[A-Za-z0-9+/]*={0,2}$/), then converts the decoded binary bytes with TextDecoder to reconstruct the original string.⁴ Invalid characters or malformed padding produce a clear error rather than garbled output, so you notice the mistake immediately instead of debugging a subtly wrong value.¹

Why the UTF-8 step comes first

btoa() interprets each input character as a single byte and throws a "character out of range" exception as soon as it meets a code point above 255, which is why raw emoji or Chinese text fails unless you first convert the string to its UTF-8 byte representation with TextEncoder. The reverse happens on decode, where the raw bytes are handed to TextDecoder so the original multi-byte characters come back intact instead of appearing as mojibake.

Everything described so far is the browser's own toolchain: btoa(), atob(), and TextEncoder. Outside the browser, every major language handles Base64 through its own libraries under a different function name, which is why half-remembered names like Python's encodebytes or Ruby's encode64() feel familiar yet refuse to resolve when you type them into the wrong environment: each name belongs to one language's library. The encoding itself is one standard, so a Base64 string produced here decodes identically in any of them. Only the call site changes, and your language's own documentation is the authority on the exact function name.

File encoding support

Any file up to 500 MB can be encoded. The tool reads the file with FileReader.readAsDataURL(), then strips the data:*/*;base64, prefix to give you clean Base64 output.⁵ This is useful for generating data URIs for images, embedding fonts in CSS, attaching PDFs as data URLs in HTML emails, or transporting binary data through text-only APIs that would otherwise reject raw bytes.

Handling large outputs

Because Base64 output can be very long (a 5 MB file produces roughly 6.7 MB of Base64), the tool provides a Download as .txt button. This creates a Blob and object URL so you can save the output without crashing the browser by trying to render megabytes of text in a textarea, and the file is written directly from the in-memory result without a second round trip through the page.

Base64 URL encoding and application contexts

Standard Base64 uses the characters A-Z, a-z, 0-9, plus sign (+), and forward slash (/), with equals signs (=) for padding. Two of these characters are not safe in URLs because browsers interpret + as a space and / as a path separator.⁶ Base64 URL encoding replaces + with a hyphen (-) and / with an underscore (_), making the output safe to embed in URL paths and query strings without percent-encoding. Padding is often omitted entirely in URL-encoded contexts because the equals sign requires encoding in query strings and the length can be inferred from the string length. JWTs use Base64 URL without padding for exactly this reason: all three parts of a JWT are Base64 URL-encoded so the token can be placed directly in an Authorization header or URL parameter.⁷

JWT access tokens and PKCE code verifiers and challenges use Base64 URL encoding.⁷⁸ When debugging an OAuth flow, you may encounter tokens in standard Base64 (with + and /), Base64 URL (with - and _), or Base64 URL without padding, and distinguishing between them is the first step before decoding. This tool handles standard Base64 and UTF-8 text. If you encounter a Base64 URL string, substitute hyphens back to plus signs and underscores back to forward slashes, then add the correct padding equals signs to make the length a multiple of four before pasting. Alternatively, paste the raw JWT into the separate JWT decoder, which handles Base64 URL format natively without any manual substitution.