> base64 encoder | text | file <

Type or paste your text into the INPUT area above. Auto-encode is on by default — the Base64 result appears in the OUTPUT box as you type. Click [ENCODE] or press Ctrl/Cmd + Enter to trigger encoding manually. Toggle --url-safe or --no-padding depending on where the Base64 will be used (JWT, OAuth, URLs → both on). Everything runs locally in your browser: no uploads, no logs, no network requests tied to your input.

Click the [upload file] button below the input area and pick a file up to 100 MB. The encoder reads it with FileReader.readAsArrayBuffer, streams the bytes through btoa in 32 KB chunks (so large files don't crash the browser), and writes the full Base64 into the OUTPUT box. For larger files, use a command-line encoder: base64 < input.bin > output.txt (macOS/Linux), or PowerShell: [Convert]::ToBase64String([IO.File]::ReadAllBytes('input.bin')).

If you want the Base64 formatted as a Data URI (e.g. data:image/png;base64,...), prepend the MIME type and ;base64, to the output, or use our dedicated Image to Base64 tool, which outputs ready-to-paste Data URIs for PNG, JPG, GIF, WebP, and SVG.

All three are defined in RFC 4648:

• Standard Base64 (§4) uses the alphabet A-Z a-z 0-9 + / with = padding. Output length is always a multiple of 4. Safe for MIME, HTTP Basic Auth, and JSON string values.

• URL-safe Base64 (§5) replaces + with - and / with _. Required when Base64 is placed in URL paths, query parameters, filenames, or JWT segments — the standard +/ characters would otherwise need percent-encoding.

• No-padding (both §4 and §5, base64url unpadded) drops trailing = characters. The length is no longer a multiple of 4, but decoders can compute the original length from the remainder mod 4. Used by JWT (base64url per RFC 7515), WebAuthn, and some CBOR/COSE implementations.

Decoders must be told which variant to expect — our Base64 Decoder auto-detects all three.

Every major language and runtime ships with Base64 encoding. Copy-paste-ready snippets:

JavaScript (browser):
btoa('Hello') // SGVsbG8=
// For UTF-8:
btoa(String.fromCharCode(...new TextEncoder().encode(s))) // UTF-8 safe

Node.js:
Buffer.from('Hello', 'utf-8').toString('base64') // SGVsbG8=
Buffer.from(bytes).toString('base64url') // URL-safe, no pad

Python:
import base64
base64.b64encode(b'Hello').decode() # SGVsbG8=
base64.urlsafe_b64encode(b'Hello').decode().rstrip('=') # URL-safe no-pad

PHP: base64_encode('Hello')
Ruby: Base64.strict_encode64('Hello') / Base64.urlsafe_encode64('Hello')
Go: base64.StdEncoding.EncodeToString([]byte("Hello")) / base64.URLEncoding.EncodeToString(...) / base64.RawURLEncoding.EncodeToString(...) (no pad)
Java: Base64.getEncoder().encodeToString("Hello".getBytes(StandardCharsets.UTF_8))
C#: Convert.ToBase64String(Encoding.UTF8.GetBytes("Hello"))
Rust: base64::engine::general_purpose::STANDARD.encode("Hello")

Shell (macOS/Linux): echo -n 'Hello' | base64 → SGVsbG8=. Use base64 -w 0 on Linux to suppress 76-column line wrapping.

Base64 output is ~33% larger than the input: every 3 input bytes become 4 output characters. Exact formula: ceil(n / 3) × 4 including padding, or ceil(n × 4 / 3) without. Plus a few more bytes of overhead if you line-wrap at 76 columns (MIME) or 64 columns (PEM).

Examples:
• 1 KB binary → ~1.37 KB Base64
• 100 KB image → ~137 KB Data URI
• 1 MB PDF → ~1.37 MB Base64 in JSON

When to avoid Base64:
• Large file transfers: a 10 MB image embedded as Base64 in HTML becomes 13.7 MB of parsed text, blocks the main thread, and can't be cached separately. Prefer <img src="/assets/photo.png">.
• Performance-critical APIs: a 500 KB Base64 payload in JSON parses ~2-3× slower than an equivalent binary endpoint.
• As a security measure: Base64 is not encryption — anyone can decode it. Use AES-GCM or similar for confidentiality.
• Database BLOBs: store raw bytes as BLOB/BYTEA, not Base64 text, to save 33% storage and avoid encode/decode round-trips.

JWT (RFC 7515) and OAuth PKCE (RFC 7636) both use URL-safe Base64 without padding, often called base64url. To produce it in this tool: enable both --url-safe and --no-padding checkboxes, then encode your text.

Programmatic equivalents:
• JavaScript: btoa(s).replace(/\+/g, '-').replace(/\//g, '_').replace(/=+$/, '')
• Node.js: Buffer.from(s).toString('base64url')
• Python: base64.urlsafe_b64encode(s.encode()).decode().rstrip('=')
• Go: base64.RawURLEncoding.EncodeToString([]byte(s))
• Java: Base64.getUrlEncoder().withoutPadding().encodeToString(bytes)

Common JWT fields that need base64url: the three dot-separated segments (header, payload, signature), OAuth PKCE code_verifier/code_challenge, WebAuthn challenges, Web Push p256dh/auth keys, and Google's Request.state parameters.

A common bug is sending a JWT with standard Base64 (+/) — APIs will reject it as malformed because the + gets URL-decoded to a space in transit.

Yes, with one caveat. This encoder produces the Base64 portion of a Data URI — the part after ;base64,. To build a complete Data URI, prepend:

data:<mime-type>;base64,<encoded-output>

Common MIME types:
• data:image/png;base64,... — PNG image
• data:image/jpeg;base64,... — JPEG image
• data:image/svg+xml;base64,... — SVG (or use data:image/svg+xml;utf8, without Base64 — usually smaller)
• data:application/pdf;base64,... — PDF file
• data:application/font-woff2;base64,... — font embed
• data:text/plain;charset=utf-8;base64,... — Base64-wrapped text

For images and SVGs, the Image to Base64 tool emits the complete Data URI ready to paste into CSS background-image, inline <img src="...">, or <object data="..."> tags.

Size warning: Data URIs over 20-30 KB hurt LCP (Largest Contentful Paint) because the browser can't preload them — keep inline Base64 images small, and prefer regular <img> with loading="lazy" for larger assets.

Yes — nothing leaves your browser. The encoder runs entirely in JavaScript using native btoa(), TextEncoder, and FileReader APIs. There are no network calls on the input content, no telemetry, no logging, no third-party analytics on what you encode. You can open the Network tab in DevTools while encoding and observe zero related requests.

However, Base64 is not encryption — it's a reversible encoding, and anyone with the output can decode it. So:
• Don't paste production secrets into chat, screenshots, or logs even in encoded form.
• For HTTP Basic Auth, the Base64 Authorization: Basic header is only secure over TLS (HTTPS). Over plaintext HTTP, it's trivially sniffable.
• For real confidentiality, use AES-GCM, age, sops, or a KMS — then Base64-encode the ciphertext for transport if needed.

For strict data-exfiltration policies, save this page offline (Cmd/Ctrl + S). The encoder works fully air-gapped after one load since there's no server dependency.

The encoder supports files up to 100 MB via the hard limit in the file handler — large enough for most images, PDFs, ZIP archives, and even short videos. Performance targets:

• < 1 MB: encoding completes in <50 ms, no UI freeze.
• 1 – 10 MB: 100-500 ms depending on CPU. Browser stays responsive because we encode in 32 KB chunks.
• 10 – 100 MB: 2-15 seconds. Output textarea may lag slightly when you paste/scroll such huge Base64 strings. Consider downloading the output as a .txt file from DevTools if needed.
• > 100 MB: blocked — browser memory overhead (input bytes + binary string + Base64 string ≈ 3-4× the file size) risks tab crashes. Use:

# macOS / Linux
base64 -i huge.bin -o huge.b64

# Windows PowerShell
$bytes = [IO.File]::ReadAllBytes('huge.bin')
[IO.File]::WriteAllText('huge.b64', [Convert]::ToBase64String($bytes))

For streaming/multi-GB workflows, see encoding large files to Base64 for a chunked approach with Node.js/Python that avoids loading everything into memory.

This encoder uses UTF-8, the same encoding used by the modern web, JSON, Linux, macOS, and almost all programming languages by default. Under the hood, text is passed through new TextEncoder().encode(input), which always produces UTF-8 bytes, and only then Base64-encoded.

Why this matters: the older JavaScript btoa() function only handles Latin-1 and throws InvalidCharacterError on characters like é, 中, or 😀. Our wrapper handles the UTF-8 conversion for you, so emoji, Chinese, Japanese, Korean, Arabic, Cyrillic, and any Unicode code point encode correctly.

If you need a different encoding:
• UTF-16 LE (Windows-native): rare — usually a sign of legacy interop. Use new TextEncoder({ fatal: true }).encode(s) anyway and convert upstream.
• ISO-8859-1 / Latin-1: manually map code points 0-255 to bytes before encoding.
• GB18030, Shift_JIS, EUC-KR: use a library like iconv-lite in Node.js to transcode first.

A subtle gotcha: if your source data is already in a non-UTF-8 encoding (e.g., reading a legacy MySQL dump), decode it first with the correct codec, then re-encode to UTF-8 before Base64 — otherwise the decoded Base64 will preserve mojibake.