InstantToolsPro
✔ 100% Free – No Signup Required
InstantToolsPro
Encode text and files to Base64 or decode Base64 back to plain text — with auto-detection, live conversion, image preview, and developer options.
Type text directly or upload a file (image, PDF, or text). It converts automatically.
The tool detects if your input is plain text (→ encode) or Base64 (→ decode) automatically.
Result updates as you type. Use developer options for URL-safe, no-padding, or line wrap.
One-click copy output to clipboard or download as a .txt file.
Base64 is a binary-to-text encoding scheme that represents binary data using 64 ASCII characters (A–Z, a–z, 0–9, +, /). It is used extensively in web development: embedding images directly in HTML/CSS as data: URIs, encoding email attachments (MIME), transmitting binary data in JSON APIs, and encoding credentials in HTTP Basic authentication headers. The core mechanism takes 3 bytes (24 bits) of input at a time and repackages them into 4 groups of 6 bits, each mapped to one of the 64 allowed characters — which is also why Base64 output is roughly 33% larger than the original data.
Encoding converts plaintext or binary data into a Base64 string (roughly 33% larger). Decoding reverses this process. This tool auto-detects which operation is needed: if your input matches the Base64 character set pattern, it decodes; otherwise it encodes.
This is the single most important thing to understand about Base64: it is not encryption, and it provides zero security. Anyone can decode a Base64 string back to its original form instantly, with no key or password required. If you see a password, API key, or token that's "just Base64 encoded," treat it as exposed rather than protected — Base64 exists purely to make binary-safe data compatible with text-only systems, not to hide it from anyone.
JWT tokens — the header and payload sections of a JSON Web Token are Base64URL-encoded JSON objects, which is why you can paste a JWT into a decoder and instantly read its claims. Data URIs — embedding small images or fonts directly inside CSS or HTML using data:image/png;base64,... avoids an extra HTTP request, useful for tiny icons or inline assets. HTTP Basic Authentication — the Authorization: Basic header sends a username:password pair Base64-encoded, which only works safely over HTTPS. Email attachments (MIME) — email protocols were originally designed for plain text, so Base64 safely embeds binary attachments like images and documents. Storing binary data in JSON or XML — since these are text formats, binary data like images or files is often Base64-encoded before being embedded in an API payload.
Standard Base64 uses + and / which have special meaning in URLs. URL-safe Base64 replaces these with - and _ respectively, making the output safe to include directly in URLs and query strings without percent-encoding. Enable this with the "URL-safe" developer option above. This is the variant used by JWTs, and it's why JWT strings look slightly different from "textbook" Base64 output. If you're encoding something that will end up in a URL, filename, or JWT, always use the URL-safe variant rather than standard Base64.
Base64 output is normally padded with one or two = characters at the end when the input length isn't an exact multiple of 3 bytes — this keeps the output length a multiple of 4 characters, which some parsers rely on. However, many modern systems (including JWTs) omit padding entirely, since it can always be reconstructed from the string length if needed. Use the "Remove padding" developer option above if your target system expects unpadded Base64.
The 76-character line wrap option exists because of RFC 2045, the original MIME specification for email. Email systems historically had line-length limits, so Base64-encoded attachments were split into 76-character lines to stay compatible with older mail transfer agents. Most modern web contexts (JSON APIs, data URIs, JWTs) don't need this and expect a single continuous string — only enable line wrap if you're specifically working with MIME-encoded email content or a system that requires it.
Assuming Base64 is secure — as covered above, it's reversible by anyone; never use it as a substitute for real encryption or hashing when protecting sensitive data. Forgetting character set issues — Base64 encodes bytes, not "text" in the abstract. If you're encoding text, know whether it should be interpreted as UTF-8, UTF-16, or another encoding when decoded, or you can end up with garbled output. Using standard Base64 where URL-safe is required — pasting a standard Base64 string with + or / directly into a URL query parameter without proper encoding can silently corrupt the data. Not accounting for the size increase — because Base64 output is about 33% larger than the input, encoding large files as inline data URIs can bloat your HTML/CSS and slow down page loads if overused.
Common questions about how Base64 encoding works and how to use this tool correctly.
No. Base64 is reversible by anyone with no key required, so it offers no security at all. Use proper encryption or hashing for anything sensitive — Base64 should never be treated as a protective measure.
The = characters are padding, added when the input length isn't a multiple of 3 bytes, to keep the output length a multiple of 4 characters. Some systems, like JWTs, omit this padding entirely — use the "Remove padding" option above if your target system expects that format.
Yes — upload an image file using the Upload File button to encode it into Base64 (with a data URI generated automatically for images), or paste a Base64 image string into the input to decode and preview the original image instantly.
This is expected behavior, not an error. Base64 encodes 3 bytes of input into 4 characters of output, which increases size by roughly 33%. This tradeoff exists to guarantee the output is safe for text-only systems like email, JSON, and URLs.
Standard Base64 uses + and / as part of its character set, both of which have special meaning inside URLs. Base64URL replaces these with - and _ so the output can be used directly in URLs, filenames, and tokens like JWTs without additional encoding.
Text encoding and decoding happen instantly in your browser using JavaScript — nothing is sent to a server. File uploads are processed client-side using the FileReader API for speed, so your files also stay local to your browser during conversion.
Yes — paste the header or payload segment of a JWT (the parts between the periods) into the input, and the tool will decode the Base64URL-encoded JSON automatically. Note that this only reveals the token's contents; it does not verify the token's signature or authenticity.