Encode plain text, HTML, or URLs to Base64 — or decode Base64 strings back to readable text. Switch between standard and URL-safe modes, encode files, and copy in one click.
Base64 is a binary-to-text encoding scheme that represents binary data using a set of 64 printable ASCII characters: A–Z, a–z, 0–9, +, and /, with = used as padding. The encoding works by taking three bytes (24 bits) of input at a time and splitting them into four groups of six bits each, then mapping each six-bit group to one of the 64 characters. This makes Base64 output approximately 33% larger than the original data. Base64 is not encryption — it is purely a way to represent binary data as text so it can be safely transmitted through systems that only handle ASCII, such as email (MIME), JSON APIs, or HTML attributes.
Standard Base64 uses + and / as the 62nd and 63rd characters. Both of these have special meaning in URLs (+ means a space in query strings; / is a path separator), so embedding standard Base64 in a URL can cause parsing errors or data corruption. URL-safe Base64 (also called Base64url, defined in RFC 4648) replaces + with - and / with _, producing strings that are safe in URLs and filenames without percent-encoding. This variant is used in JSON Web Tokens (JWTs), OAuth 2.0 flows, and data URIs embedded in query parameters. Toggle the “URL-safe” switch above to convert between both formats. For manipulating the character count of encoded strings, our Character Counter is a quick companion tool.
Common use cases include: embedding images directly in HTML or CSS as data URIs (src="data:image/png;base64,...") to reduce HTTP requests; transmitting binary data in JSON APIs which only support text; attaching files in email via MIME encoding; storing binary keys, certificates, or tokens in environment variables or configuration files; and passing binary data in URL query parameters. Base64 is also used in HTTP Basic Authentication, where the credentials are encoded as username:password before being placed in the Authorization header. For cases where you need to check the size of your plaintext before encoding, use our Word Counter for a full character and byte breakdown.
Switch the tool to Decode mode using the button at the top, paste your Base64 string into the left panel, and the decoded plain text appears instantly on the right. A valid Base64 string contains only the characters A–Z, a–z, 0–9, +, / (or -, _ in URL-safe mode), and optional = padding at the end. If your string contains other characters, you will see a decoding error in red. Note that if the original data was binary (an image, PDF, or executable), the decoded output will contain unprintable characters and may not display meaningfully as text.
Yes. Expand the “File to Base64 Encoder” section above, then drag and drop any file onto the upload zone or click to browse. The tool reads the file entirely in your browser using the FileReader API — nothing is uploaded to any server. The resulting Base64 string is displayed in the output box and can be copied directly or downloaded as a ready-to-use data: URI. Data URIs are particularly useful for embedding small images or fonts directly into CSS or HTML, avoiding a separate HTTP request. File encoding works for any file type: PNG, JPEG, PDF, SVG, WOFF fonts, and more.
No — Base64 encoding increases file size by approximately 33% (every 3 bytes becomes 4 characters). The overhead stat in the tool shows you the exact increase for your data. Base64 is a representation format, not a compression algorithm. If reducing file size is your goal, you should compress the data first (gzip, Brotli, zlib) and then Base64-encode the compressed bytes if text transport is required. For working with and compressing PDFs directly, our Compress PDF tool handles that workflow without any encoding step needed.
Base64 encodes data in 3-byte blocks. If the input length is not divisible by 3, padding characters (=) are added to the end to complete the final block. One trailing = means the original data had one byte of padding (input length was 1 mod 3), and two == means two bytes of padding (input length was 2 mod 3). Padding is required by the standard for correct decoding, though some implementations omit it. If you are decoding a string that is missing its padding, the decoder may fail; you can manually add = characters to bring the string length to a multiple of 4.
No. Base64 encoding is completely reversible and provides no security whatsoever. Anyone who has your Base64 string can decode it instantly with any standard library or with this very tool. It should never be used to protect sensitive data such as passwords, API keys, or personal information. For security, use proper encryption (AES-GCM, RSA-OAEP, etc.) or hashing (bcrypt, Argon2 for passwords). A common mistake is to see a Base64 string in a source file or API response and assume it is encrypted — it is not. For other text manipulation tasks that are similarly easy to do in-browser, see the Case Converter and Text to Slug Generator.
By default, Base64 output is a single continuous string. However, RFC 2045 (the MIME email standard) specifies that Base64 lines should be wrapped at 76 characters with a CRLF line break. Some systems — particularly older email clients and PEM certificate files — require this wrapped format. Enable the “Line Wrap” toggle above to insert line breaks every 76 characters in the output. For most modern web and API use cases (JSON, HTML data URIs, JWTs), unwrapped single-line output is preferred and expected. If you are pasting Base64 into a .pem or .crt file, the wrapped format is typically required.