Free · Byte-exact · Local
Encode UTF-8 text or the exact bytes of a local file as standard Base64, URL-safe Base64, or a complete Data URL. Choose padding and line wrapping for the system that will consume it.
text
Encode once. Transfer exactly.
base64
RW5jb2RlIG9uY2UuIFRyYW5zZmVyIGV4YWN0bHkuCanonical output30 UTF-8 bytes
Encode text and binary data
Enter text or choose a local file, select the target alphabet and formatting, then copy the encoded value or download it as a text file.
Loading the Base64 encoder…
Enable JavaScript to encode text and files, generate Data URLs, copy output, and download results. The guide below remains readable without JavaScript.
A clear three-step workflow
Correct output depends on the source bytes and the destination protocol. Decide those explicitly instead of assuming every Base64-looking field follows the same convention.
Type or paste text to encode it as UTF-8. Choose a file when byte-for-byte binary identity matters; the encoder reads the file without first converting it to text.
Use standard Base64 for a field that specifies the +// alphabet. Use Base64URL for URL, filename, JWT, or other protocols that specify -/_.
Retain = padding unless the consuming specification omits it. Add line breaks only when a MIME-style format requires them, or generate a Data URL with a verified media type.
Transport-friendly, not smaller
Base64 maps arbitrary bytes to a limited printable ASCII alphabet. It reads 24 source bits at a time, divides them into four six-bit values, and represents those values with characters. This makes binary data easier to carry through text-oriented systems such as JSON, XML, email, configuration files, form fields, and command-line arguments that cannot safely contain every byte value.
The transformation is reversible and deterministic: the same byte sequence under the same alphabet and padding convention produces the same canonical output. Base64 does not compress data. Four output characters represent three source bytes, so the core payload is about one third larger, before line breaks or a Data URL header. A 3 MB file becomes roughly 4 MB of Base64 text, and both forms may coexist in memory while a browser encodes it.
Encoding also does not attach a filename, MIME type, checksum, signature, or encryption key. If a protocol needs those properties, carry them in explicit fields or in a defined container. A complete Data URL includes a media-type label, but ordinary Base64 is just the encoded payload. Do not guess a destination’s contract from a sample string alone.
Base64 is most useful at a boundary that requires text. When a system already accepts binary request bodies, multipart uploads, blobs, or object storage, sending the original bytes is usually smaller and more efficient. Choose Base64 because the receiving format calls for it, not as a universal wrapper for every file.
Characters become bytes first
When you enter text, LiveParse converts Unicode code points to UTF-8 bytes and Base64-encodes those bytes. ASCII letters use one byte each, while Korean, emoji, and many other characters use multiple bytes. Two strings that look similar can also contain different Unicode code-point sequences and therefore produce different output.
A selected file is read as raw bytes, not interpreted with a character set. This preserves images, PDFs, fonts, archives, database fixtures, and any other binary format. Reopening a binary file as text before encoding can change bytes through newline conversion or replacement characters.
Base64 itself never says “UTF-8.” If a receiver decodes the bytes and applies Latin-1, UTF-16, or a platform default, the visible result may differ. Document UTF-8 in your API schema or media type whenever the original content is text.
After encoding a fixture or protocol value, use the Base64 decoder to recover it. Compare hashes or exact bytes for files and compare explicit UTF-8 bytes for text. Visual equality alone can miss line-ending and Unicode-normalization differences.
Select the alphabet by protocol
The two RFC 4648 alphabets represent the same six-bit values. Base64URL substitutes two characters so encoded data fits URL and filename contexts without the same escaping problems.
A–Z a–z 0–9 + /A–Z a–z 0–9 - _; only positions 62 and 63 change.= usually includedOften omitted in compact formats, but include or remove it only as the target specification directs.JSON fields, MIME, files, Data URLsJWT segments, URLs, cookies, filenames, and protocols that explicitly name base64url.Inserted into a URL unescapedAssuming “URL-safe” means the entire surrounding value is authenticated, validated, or safe to trust.Compare alphabets, padding, JWT usage, and migration details →
Stable text for stable bytes
Base64 processes complete three-byte groups cleanly. If one source byte remains, two encoded symbols carry its bits and two = characters complete the four-character group. If two bytes remain, three symbols and one = are used. A source length divisible by three needs no padding. The equals signs are markers, not encrypted content and not additional decoded bytes.
RFC 4648 does not add line feeds unless another referring specification requires them. Continuous output is the safest default for JSON, database fields, environment values, HTTP parameters, and most modern APIs. The optional 76-character wrap supports MIME-style contexts that explicitly expect folded lines. Never add line wrapping merely for visual appearance when the receiving parser treats whitespace as an error.
A canonical encoder sets unused pad bits to zero and uses the selected alphabet consistently. That guarantees one normalized representation for a given byte sequence under the chosen padding policy. Canonical form matters when encoded text participates in signatures, hashes, cache keys, comparisons, test snapshots, or deduplication. Two permissively decodable strings should not silently become two logical identities.
LiveParse generates canonical bit patterns. To audit an external value, use the decoder’s strict validation, which checks alphabet, length, padding position, whitespace policy, and pad bits. A decode-and-re-encode round trip can normalize a representation, but signature verification must still follow the original protocol’s exact serialization rules.
From local bytes to portable text
Choose a local file when you need its exact bytes. The browser reads up to 10 MB in the current tab and produces Base64 without posting the file to a conversion endpoint. The limit protects browser responsiveness because the source bytes, encoded string, and visible output can occupy memory at the same time. For very large assets, use a streaming command-line tool or application code instead.
A Data URL embeds content directly in a URL-shaped string: data:, a media type and optional parameters, the ;base64 marker, a comma, and standard padded Base64. For example, a small PNG can begin with data:image/png;base64,. Data URLs are convenient for tiny self-contained fixtures, CSS assets, demonstrations, and clipboard exchange, but their size makes them poor substitutes for ordinary hosted files.
Set the media type from a trustworthy source. A filename extension and browser-provided type can be missing or wrong, and typing image/png does not convert arbitrary bytes into a PNG. The label tells a consumer how to interpret content; it does not validate that content. Avoid embedding untrusted HTML or SVG in a page, because those formats can contain active behavior depending on context.
The encoder does not execute or preview the selected file. If you later inspect a Data URL with LiveParse, the decoder previews only recognized PNG, JPEG, GIF, and WebP raster bytes. It never renders decoded HTML or SVG. This narrow preview policy keeps byte conversion separate from content execution.
For long results, the interface shortens only the on-page preview to protect the tab. Copy and download use the complete encoded output. The downloaded text retains the alphabet, padding, wrapping, and Data URL options you chose.
Visible data in another alphabet
Base64 uses a public, reversible mapping and no secret key. Anyone who can read an encoded value can usually recover the original bytes immediately. It does not hide passwords, API keys, session cookies, personal data, proprietary documents, or internal endpoints. The fact that the text is unfamiliar to a person does not make it confidential.
Base64 also provides no integrity or authenticity. An attacker can alter encoded text and produce different decoded bytes, often without an obvious visual clue. Use an authenticated encryption scheme when content needs confidentiality and tamper detection, or a digital signature or message authentication code when integrity and sender authenticity are the goal. Transport encryption such as HTTPS protects data in transit but does not change what Base64 itself provides.
This encoder performs conversion locally: entered text and selected file contents are not uploaded to a Base64 API. That reduces disclosure to a remote conversion service, but it does not control browser extensions, clipboard history, downloaded files, screenshots, backups, or other software on the device. Work on a trusted device, clear sensitive input afterward, and see the privacy page for the full processing model.
Avoid integration surprises
Charset, normalization, or newline differenceSpecify UTF-8, compare code points and bytes, and normalize Unicode or line endings only when the application contract requires it.Standard + / = charactersUse Base64URL when the protocol permits it, or percent-encode standard Base64 as part of constructing the complete URL.Wrong padding or wrapping conventionFollow the receiving specification exactly. Do not remove = or insert line feeds simply because another parser accepts both.Binary was converted through textEncode the original file bytes directly, then decode and compare a cryptographic hash or exact byte length.Purposeful use cases
Encode a small UTF-8 or binary sample exactly as the API schema requires, keep the alphabet and padding documented, and verify it with a round trip before adding it to tests or documentation.
Generate URL-safe output for a field that explicitly uses RFC 4648’s URL alphabet. For JWT work, encoding a header or payload is only serialization; signing and validating the complete token are separate security operations. Read JWT decode vs verify before treating claims as trusted.
Embed a trusted tiny raster image or fixture with an accurate media type. Measure the expanded size and prefer a normal asset URL when caching, readability, updateability, or page weight matters.
Represent bytes in JSON, XML, SQL text, or a configuration format when the contract has no binary type. Store content length, media type, and integrity information separately if consumers need them.
Questions answered
Enter the text in the encoder. LiveParse converts it to UTF-8 bytes and encodes those bytes with the alphabet, padding, and wrapping options you select. Copy the result or download it as a text file, then document UTF-8 for the receiving system.
Yes. Choose the local file and the encoder reads its raw bytes rather than treating it as text. Files are limited to 10 MB to protect browser responsiveness. For large files, prefer a streaming CLI or application library and transfer raw binary when possible.
Use the format named by the destination. Standard Base64 uses + and /; Base64URL replaces them with - and _. Base64URL often omits padding in compact protocols. The comparison guide shows the exact differences.
Standard canonical Base64 normally includes the necessary = markers. Some protocols, including common Base64URL uses, explicitly omit them. Keep padding unless the receiver’s specification says otherwise; parser tolerance is not a substitute for a defined wire format.
Each three source bytes become four encoded characters, so the payload expands by about 33 percent before line wrapping or a Data URL header. Padding adds at most two characters. Base64 improves text compatibility, not compression.
Use the verified type of the source bytes, such as image/png for a real PNG or text/plain;charset=utf-8 for UTF-8 plain text. A label does not inspect or convert content, so do not trust a filename extension alone for untrusted files.
No. Anyone can reverse ordinary Base64 without a key, and it does not detect modification. Use authenticated encryption, secret storage, access controls, and secure transport appropriate to the threat model. Base64 may carry ciphertext, but it does not create it.
The encoding operation reads input in the current browser tab and does not send it to a conversion API. Clipboard managers, downloads, extensions, and other device software remain outside that boundary. Review the LiveParse privacy page for details.