Base64 kodēšana / dekodēšana

A complete Base64 toolkit that never leaves your browser

Base64 turns binary data into plain ASCII text so it can travel safely through systems built for text — email bodies, JSON payloads, URLs, HTML, and CSS. This tool encodes and decodes Base64 for both text and files, and unlike most popular Base64 websites it runs entirely on your device. Nothing you paste or drop is ever uploaded, which matters when the data is an access token, an API key, or anything else you'd rather not hand to a third-party server.

It is built to handle the cases simpler tools get wrong: full Unicode (including emoji and non-Latin scripts), URL-safe Base64URL, MIME and PEM line wrapping, and decoding text that was originally encoded in a non-UTF-8 character set.

Decode anything — with charset control and a forgiving parser

Pasted Base64 is often messy: it picks up line breaks from email wrapping, loses its trailing = padding in a terminal, or arrives as a full data: URI. The decoder cleans all of that up automatically — stripping whitespace, accepting URL-safe characters, restoring padding, and unwrapping data URIs — and if something is genuinely invalid it points to the exact character and position instead of failing silently.

Because Base64 stores raw bytes with no character-set label, decoded text can look garbled when it didn't originate as UTF-8. The Decode as selector lets you reinterpret the same bytes as UTF-16, Latin-1, Windows-1252, ASCII, Shift_JIS, or GBK. Switch to the Hex view to inspect the raw bytes directly when you're debugging binary payloads.

Files and images, with preview and ready-to-paste snippets

Drop a file, click to browse, or simply paste an image from your clipboard. Images preview inline, and the tool detects the file type from its magic bytes — so a decoded blob is correctly recognized as PNG, JPEG, GIF, WebP, PDF, and more, and downloaded with the right extension.

For embedding assets, encode an image and copy a ready-made data URI, a CSS background-image rule, an <img> tag, or a favicon <link> — no need to assemble the string by hand. This is exactly what developers need when inlining favicons, email logos, or icon sprites into a single-file page.

Why this beats other free Base64 tools

Many free Base64 tools — including ones from popular sites like base64decode.org and base64encode.org — process your input server-side. That means your JWT tokens, API keys, and private file contents are transmitted to a remote server you don't control. UtiloKit's Base64 tool runs 100% in JavaScript in your browser. You can even disconnect from the internet after the page loads and it still works perfectly.

CyberChef is excellent but has a steep learning curve for simple encoding tasks. base64.guru handles text well but uploads files to their servers. TinyWow imposes daily limits on free users. UtiloKit offers MIME line-wrapping for email compatibility, PEM formatting for certificates, charset-aware decoding for international text, URL-safe Base64URL support for JWT and OAuth tokens, and file type detection for decoded binaries — all free, all unlimited, all private.

Works on iPhone, Android and any device — no app needed

This Base64 encoder and decoder is fully responsive and works on every device with a modern browser. On iPhone and Android, you can paste text directly from your clipboard, pick files from the Files app or camera roll, and download the encoded or decoded result — all without installing anything. The interface is optimised for small screens at 375px width and up.

Because the tool runs entirely offline once loaded (no server calls, no dependencies), it keeps working in situations where web-based tools from base64decode.org or CyberChef might struggle — inside a VPN, in airplane mode after loading, or on a device with restricted network access. Developers on mobile can decode JWT payloads, engineers on iOS can inspect data URIs, and anyone can embed images in CSS without a desktop machine.

How Base64 encoding works: the step-by-step algorithm

Base64 works by grouping input bytes into three-byte chunks and converting each chunk into four printable characters. First, the raw bytes are laid out as a continuous bitstream. Every 6 bits of that stream maps to an index into the 64-character alphabet: uppercase A–Z (indices 0–25), lowercase a–z (26–51), digits 0–9 (52–61), + (62), and / (63). Because 6 bits can represent 64 values and 8 bits represent 256, encoding three 8-bit bytes (24 bits) always yields exactly four 6-bit groups (also 24 bits) — and four printable characters. This fixed 3-to-4 conversion ratio is why Base64 output is always approximately 33% larger than the input.

A worked example makes the algorithm concrete. Encoding the word Man starts with its ASCII values: M = 77, a = 97, n = 110. In binary those are 01001101 01100001 01101110. Laid end-to-end as 24 bits and split into four 6-bit groups: 010011 (19 → T), 010110 (22 → W), 000101 (5 → F), 101110 (46 → u) — producing the Base64 string TWFu. When the total input length is not a multiple of 3, the final group is padded with zero bits to reach a full 6-bit boundary, and one or two = padding characters are appended to signal that the last encoded group was short. One = means the last input group had 2 bytes; two == means it had only 1 byte.

Decoding reverses the process exactly: each character is looked up in the alphabet to recover its 6-bit index, the four groups are concatenated into 24 bits, and those bits are split back into three bytes. Padding characters are discarded. Because the mapping is a simple lookup table with no key and no state, decoding is instantaneous — there is no secret to discover and no computation to brute-force. This is why Base64 provides zero confidentiality and must never be confused with encryption.

Why Base64 was invented: SMTP, MIME, and the 7-bit ASCII problem

The need for Base64 is rooted in decisions made when the internet was young. SMTP, the email protocol, was designed in the early 1980s for 7-bit ASCII text. Mail servers passed messages through relay nodes that stripped the 8th bit of every byte — a practice inherited from telegraph networks. Binary files, images, and any non-English text that used byte values above 127 were silently corrupted in transit. Sending a photo or a program executable by email was simply impossible with raw bytes.

MIME (Multipurpose Internet Mail Extensions), standardised in RFC 2045 in 1992, solved this by defining a set of content-transfer encodings that made binary data safe for ASCII-only infrastructure. Base64 was specified as MIME's encoding for arbitrary binary because it converts every byte into characters from the safe 7-bit ASCII range, surviving every mail relay that strips the high bit. The same underlying problem — a text-oriented channel that cannot reliably carry arbitrary bytes — appears repeatedly across the web stack: HTTP headers cannot contain raw bytes, cookies are restricted to a subset of ASCII, JSON and XML are text formats where NUL bytes or unescaped binary would break parsing, and HTML attributes cannot contain angle brackets or quotes unescaped. Base64 is the universal answer to all of these constraints because it transforms any binary sequence into a string that any text-oriented system can store and forward without modification.

Today SMTP is mostly 8-bit clean and many email servers support the 8BITMIME extension, but Base64 encoding of attachments persists because the MIME standard is deeply embedded in every mail client and server ever written. The encoding that fixed 1980s email is now woven into JWTs, data URIs, SSH keys, TLS certificates, HTTP Basic Auth, and dozens of other modern standards — all because the same 7-bit safety requirement keeps resurfacing in new contexts.

Base64 variants: standard, URL-safe, MIME, and padding-free

There is no single Base64 — there are several closely related variants that differ in two characters of their alphabet and in how they handle line breaks and padding. Standard Base64 (RFC 4648 §4) uses + and / as the 62nd and 63rd characters and requires = padding. This is the variant used by MIME email attachments, PEM certificates, and most general-purpose encoding libraries. The + and / characters are the source of friction everywhere else.

URL-safe Base64 (RFC 4648 §5, also called Base64url) replaces + with - and / with _. This matters because + means a space in URL query strings and / is the path separator — a standard Base64 string embedded in a URL would be misinterpreted or require percent-encoding, making it longer and harder to read. Base64url is the variant mandated by the JWT specification (RFC 7519), OAuth 2.0 PKCE, and any context where the encoded string appears in a URL, filename, or HTTP header. JWT additionally drops the trailing = padding entirely, because the length of a JWT segment can be inferred from the overall structure, and padding characters in URLs must otherwise be percent-encoded as %3D.

MIME Base64 (RFC 2045) is standard Base64 with a mandatory line break every 76 characters, using CRLF (\r\n). This was required to keep email lines within the traditional 76-character width imposed by early mail systems. PEM (the format used for X.509 certificates and SSH keys) uses the same 64-character line length with headers like -----BEGIN CERTIFICATE-----. When interoperating between systems, the variant matters: a URL-safe string fed to a standard decoder will fail on the - and _ characters, and a MIME-wrapped string fed to a decoder that doesn't strip newlines will fail on the line breaks. A robust decoder — like the one in this tool — normalises all variants automatically.

Where Base64 appears in practice — and why it is not encryption

Base64 is embedded in more places than most developers realise. JWT (JSON Web Tokens) encode both their header and payload as Base64url — paste any JWT into a decoder and you can read the claims (user ID, roles, expiry) in plain text immediately. The signature prevents tampering, but the payload is not encrypted; anyone who intercepts a JWT can read everything in it. HTTP Basic Authentication encodes username:password as Base64 and sends it in the Authorization header — over plain HTTP this is completely insecure because the password is trivially recoverable. Basic Auth is only safe over HTTPS, where TLS encrypts the entire request including the header.

Data URIs (src="data:image/png;base64,...") embed file contents directly into HTML or CSS, eliminating an HTTP round-trip for small assets. Favicons, inline SVG icons, and small UI sprites are common candidates. SSH public keys in ~/.ssh/authorized_keys are Base64-encoded DER structures. X.509 certificates in PEM format are Base64 with header and footer lines. Email attachments have been Base64-encoded since MIME was invented. Storing binary blobs in JSON or XML — common in REST APIs that exchange file content — uses Base64 because neither format has a native binary type.

The most important misconception about Base64 is that it provides any form of security. It does not. Base64 is a reversible encoding with a public, fixed algorithm and no key — decoding is a lookup table operation that any programmer can implement in ten lines. Obfuscating a password or API key by Base64-encoding it offers exactly zero protection; automated scanners routinely decode Base64 strings in source code and configuration files as part of credential-harvesting attacks. If data needs to be confidential, encrypt it with AES or a similar cipher before (optionally) encoding the ciphertext as Base64 for transport. The encryption provides the security; Base64 only provides safe ASCII transport.