Base64 Encoder / Decoder

BASE64 DECODE DEVELOPER ENCODE

About this tool

Encode text or files to Base64 and decode Base64 strings — instantly, in your browser.

Encode text or files to Base64 and decode Base64 strings instantly in your browser. URL-safe mode, file upload, image preview, and one-click copy. Free, no signup.

RT-DEV-003 · Developer Tools

0 characters

URL-safe mode (replaces +→-, /→_, removes = padding) Wrap at 76 characters (for email / MIME compatibility)

Base64 Output

0 characters

Drop a file here, or click to select Any file type · up to 5 MB

Include data: header (produces a full data URI — uncheck for raw Base64 only)

Base64 Output

0 characters

URL-safe input (auto-normalises -→+, _→/ before decoding)

Binary data detected — cannot display as text.

Decoded Output

0 characters

How to Use the Base64 Encoder / Decoder

Choose Encode or Decode mode

Click the Encode or Decode pill button at the top of the tool card. The active mode is highlighted in orange.

Type your text or drop a file

For encoding: switch between the Text and File sub-tabs. In Text mode, type or paste any text — Unicode including Malay, Chinese, and Tamil scripts is fully supported. In File mode, drag a file onto the drop zone or click to browse (up to 5 MB).

Decoding: paste and the tool detects automatically

Paste any Base64 string into the Decode input. The tool automatically detects whether it is readable text, an image data URI (which shows an inline preview), or binary data (which offers a Download button). Enable URL-safe input if your string uses - and _ instead of + and /.

Copy or download your result

Click Copy to send the result to your clipboard, or Download to save it as a file. Everything runs entirely in your browser — nothing is sent to any server.

Base64 — The Invisible Encoding Standard Powering the Web

What Is Base64 and Why Do APIs Use It?

Base64 represents binary data as ASCII text using a 64-character alphabet: the 26 uppercase letters A–Z, the 26 lowercase letters a–z, the 10 digits 0–9, and the two symbols + and / — with = used as padding to align output to a multiple of four characters. The encoding converts every 3 bytes of binary input into 4 printable output characters, using exactly 6 bits of information per character. The name comes directly from this 64-symbol alphabet.

The concept was developed in the 1980s as a practical solution to a fundamental incompatibility: the early internet's email systems were built on protocols that could only carry 7-bit ASCII text. Sending a photograph or a Word document as an email attachment required transforming those arbitrary bytes into a stream of printable characters that any SMTP relay would pass through unmodified. The MIME standard (Multipurpose Internet Mail Extensions) formalised Base64 encoding for this purpose in RFC 2045, published in 1996, and the encoding has been a cornerstone of internet infrastructure ever since.

Today, Base64 appears in a surprisingly wide range of modern web technologies that most developers encounter daily without consciously recognising it. HTTP Basic Authentication encodes username:password as Base64 and includes it in every request's Authorization header. JWT tokens (JSON Web Tokens) — the authentication mechanism used by virtually every modern web API — consist of three Base64URL-encoded segments joined by dots. Data URIs embed images, fonts, and other binary assets directly into HTML and CSS: a small icon encoded as data:image/png;base64,iVBOR... inside a stylesheet eliminates one HTTP request entirely. API payloads routinely carry Base64-encoded file attachments, audio samples, and encrypted blobs because JSON only natively supports text strings. For every ASEAN developer working with REST APIs, government identity systems, or e-commerce platforms, Base64 is an unavoidable daily reality.

Base64 in Email: MIME, Attachments and Why Encoded Files Are Bigger

The original MIME standard specified that binary email attachments must be Base64-encoded before transmission because the underlying SMTP protocol was designed around a 7-bit ASCII network where bytes with values above 127 would be stripped or corrupted by relay servers. Base64 solves this by representing every possible byte value using only safe, printable characters that every ASCII-compliant relay preserves faithfully.

The cost of this safety is a size overhead. Because Base64 encodes 3 bytes of binary into 4 characters, output is always approximately 33% larger than the original file: a 1 MB image attachment becomes roughly 1.33 MB in Base64. This explains why email clients warn you that your "1 MB" attachment looks larger in the raw message source. Modern email clients — Outlook, Gmail, Thunderbird — decode Base64 attachments automatically and invisibly, so users never see the encoded form. However, developers building email parsing systems, newsletter platforms, or compliance archiving tools must handle this decoding explicitly.

Singapore government emails sent via gov.sg use S/MIME certificates for digital signing. An S/MIME signature itself is a DER-encoded ASN.1 structure that is Base64-encoded before being attached to the email as a multipart/signed MIME part. When a government agency digitally signs correspondence and distributes public keys via email, those certificates are delivered as Base64-encoded PEM files — another example of Base64 carrying security-critical data across the public email infrastructure of the region.

"Every JWT token you've ever seen is three Base64URL-encoded strings joined by dots — and that includes the SingPass tokens used for Singapore government digital identity."

Common Developer Use Cases: Images in CSS, JWTs, and API Payloads

CSS data URIs are one of the most visible uses of Base64 in front-end development. A small PNG icon or SVG graphic can be embedded directly in a stylesheet as background: url('data:image/png;base64,...'), eliminating a network request at the cost of a slightly larger CSS file. For icons under about 4 KB, this trade-off typically benefits performance because the saved HTTP round trip — often 100–200 ms on typical mobile networks in Southeast Asia — outweighs the modest file size increase.

JWT structure and SingPass: a JWT looks like xxxxx.yyyyy.zzzzz — three segments separated by dots. The first is the header (encoding algorithm), the second is the payload (claims such as user ID, roles, and token expiry), and the third is the cryptographic signature. All three segments are Base64URL-encoded — meaning they use - and _ instead of + and /, and omit = padding, so the token is safe to include in URLs and cookies. Singapore's SingPass API uses OpenID Connect, which issues identity assertions as JWTs with Base64URL-encoded payloads. Paste any JWT segment into the Decode tab of this tool and you can read the raw JSON header and payload — though the signature cannot be verified without the issuer's private key.

REST API file uploads: when a mobile or web application needs to transmit a photo, a scanned document, or an audio recording to a REST API that accepts JSON, Base64 encoding is the conventional approach. The binary file is encoded and placed in a string field of the JSON request body — avoiding the more complex multipart/form-data content type. The trade-off is the 33% size increase and the need for the API server to decode before processing. When building ASEAN fintech or e-KYC (know your customer) integrations — common use cases for developers in Singapore, Malaysia, and Indonesia — always verify whether the API expects standard Base64, Base64URL, or a raw multipart upload, as mixing these up causes silent data corruption that is difficult to diagnose in production.

For mobile developers, a practical note: decoding a large Base64 string (over 1 MB) on the main UI thread will freeze the interface on both Android and iOS. Always move large Base64 decode operations off the main thread using a Web Worker (browser), a background dispatch queue (iOS), or a Coroutine with a background dispatcher (Android Kotlin). This tool handles all processing inside a single browser IIFE and uses native FileReader and TextEncoder/TextDecoder for maximum efficiency, but for production applications serving the large mobile-first audiences of the ASEAN region, always profile Base64 operations before shipping.

10 Facts About Base64 Encoding

Base64 encoding increases file size by approximately 33% — every 3 bytes of binary data becomes 4 Base64 characters.

The "Base" in Base64 refers to the 64-character alphabet used: A-Z (26), a-z (26), 0-9 (10), + and / (2) = 64 total.

JWT uses Base64URL encoding, not standard Base64 — the difference is - instead of + and _ instead of /, making it safe in URLs.

The = padding at the end ensures encoded length is divisible by 4 — you may see one or two = signs, or none in URL-safe mode.

Base64 was specified in RFC 2045 in 1996 for MIME email encoding — though the concept predates this, having been in use since the 1980s.

Singapore's SingPass uses JWT tokens with Base64URL-encoded payloads for its digital identity assertions — tokens you can decode with this tool.

The atob() and btoa() JavaScript functions provide native Base64 encoding — but they only handle Latin-1 characters; Unicode requires extra handling.

Google Fonts uses Base64-encoded font subsets embedded in CSS — reducing HTTP requests for small icon fonts at the cost of slightly larger CSS files.

Inline SVG images in HTML can be Base64-encoded for embedding in img src attributes — useful for offline applications or email clients that block external images.

The longest Base64-encoded file practically handled by browsers is around 100 MB — beyond that, performance degrades significantly due to JavaScript string limitations.

Frequently Asked Questions

No — Base64 is encoding, not encryption. Encryption scrambles data using a secret key so only authorised parties can read it. Base64 simply converts binary data into a different text representation using a fixed, public alphabet. Anyone with a Base64 decoder (including this tool) can instantly reverse the process without any key. Never use Base64 alone to protect sensitive data — always layer it with proper encryption such as AES-256 if you need confidentiality.
Binary data uses 8 bits per byte — 256 possible values. Base64 uses only 64 characters (6 bits of information per character). To represent 3 bytes (24 bits), you need 4 Base64 characters (24 ÷ 6 = 4). This means every 3 bytes become 4 characters — a size increase of exactly 33%. This overhead is the unavoidable trade-off for having safe, printable, text-compatible data that travels reliably over any ASCII-safe channel.
Standard Base64 uses +, /, and = — characters that have special meaning in URLs (+ is decoded as a space, / is a path separator, = is a key-value delimiter). RFC 4648 §5 defines Base64URL, which replaces + with -, / with _, and removes the = padding. Use URL-safe mode whenever your Base64 string will appear in a URL, a JWT token, a cookie, or any system that processes URLs without additional percent-encoding.
A data URI is a URL that contains the file contents directly, rather than pointing to an external resource. The format is data:[MIME type];base64,[encoded data]. For example, a small PNG image embedded in a CSS stylesheet might look like data:image/png;base64,iVBOR.... Data URIs eliminate a separate HTTP request for small assets, which benefits performance on high-latency networks. This tool's File encoder outputs full data URIs by default (toggle off the "Include data: header" option for raw Base64 only).
A JWT looks like xxxxx.yyyyy.zzzzz — three segments separated by dots. Copy the first segment (header) or second segment (payload) and paste it into the Decode tab of this tool. Each segment is Base64URL-encoded (URL-safe, no padding). The tool will auto-normalise the URL-safe characters and show you the raw JSON. The first segment reveals the signing algorithm; the second reveals the claims (user ID, roles, expiry). The third segment is the cryptographic signature — decoding it shows raw bytes, not the original secret.
Base64 encodes every 3 bytes into 4 characters. If the input length is not a multiple of 3, one or two = padding characters are appended to make the total output length a multiple of 4. One = means 2 bytes were left over in the last group; == means only 1 byte was left. URL-safe Base64 (Base64URL) strips this padding because the decoder can infer the length from context — both padded and unpadded variants decode to exactly the same bytes.
Yes — Base64 can encode any binary file: images (PNG, JPEG, WebP, GIF, SVG), PDFs, audio files, fonts, archives, spreadsheets, or executables. This tool's File tab uses the browser's native FileReader.readAsDataURL() API to read the raw bytes and produce a Base64 data URI. Files up to 5 MB are supported. For larger files, use a command-line tool (base64 on Linux/macOS, certutil -encode on Windows) or a server-side library.
MIME (Multipurpose Internet Mail Extensions) is the standard that allows email messages to carry attachments, HTML content, images, and other non-ASCII data. RFC 2045 specifies that binary attachments must be encoded using Base64 before transmission, because original SMTP relays only passed 7-bit ASCII bytes safely. Modern email clients decode Base64 attachments automatically. MIME also defines content type headers — such as image/png or application/pdf — that browsers and email clients use to decide how to handle decoded content. These same MIME types appear in the header of Base64 data URIs.
A valid standard Base64 string contains only the characters A-Z, a-z, 0-9, +, /, and optionally trailing = padding — and its total length is always a multiple of 4. A valid URL-safe Base64 string uses - and _ instead of + and /, and may omit padding. This tool auto-detects both variants and will show an error if the input contains invalid characters or has an incorrect length. When in doubt, paste the string into the Decode tab — a successful decode confirms validity.
100% free, forever. No account required, no subscription, no hidden limits. All encoding, decoding, and file processing runs entirely in your browser using native JavaScript — your text and files are never sent to any server. RECATOOLS is funded by contextual advertising, not paywalls. The tool works with or without ad consent enabled and is safe to use with sensitive developer data such as API keys, JWT tokens, and private configuration files.

Base64 Encoder / Decoder