Cómo usar esta calculadora
Why Base64 exists — and when to reach for this tool
Base64 solves a transport problem, not a secrecy problem. Many channels — email bodies, JSON fields, URL query strings, HTTP headers, and plain-text boxes — are built for text, and some of them are picky about which text. Raw bytes, accented characters, nulls, and line breaks can be mangled in transit or rejected outright. Encoding converts those bytes into a safe alphabet of 64 characters (A–Z, a–z, 0–9, plus, and slash), so the payload survives the trip untouched. That is why tokens, certificates, API keys, and small binaries so often arrive as long strings ending in equals signs. Use this tool when you need to put binary data into a text-only channel, when you are debugging a token or a configuration value, or when something you were sent looks like Base64 and you want to see what it actually says before acting on it.
Knowing when not to use Base64 is half the skill. It adds no secrecy — anyone can decode it in seconds, and a JWT payload decoded here says nothing about whether the token is genuine. It also expands data by about a third, so it is the wrong tool for shrinking anything. Encode when a system demands it: an Authorization header, a data-URI, a config file that only accepts ASCII, or a paste into a form that drops binary files. Decode when you received a Base64-looking string — from a log line, an email, or a chat — and you want to read the actual content before acting on it. Everything you type or load is processed entirely in your browser; the page never uploads, logs, or stores your input, which matters when the data is a credential.
Encoding and decoding: fields, buttons, and strictness
The tool has one input box, two direction buttons, and a file loader. Type or paste your text into the box and press Encode to turn it into Base64; paste a Base64 string and press Decode to get the text back. The same box also accepts files: choose one from your device and the tool reads it as bytes, encodes the whole thing, and places the result back in the box — so you can encode a small PDF, an image, or a key file without ever opening it. The output box shows the result, the Copy button copies it ready for a header or a config field, and Clear wipes both boxes and the size comparison so you can start over. A size bar underneath compares input and output, updating with every encode or decode, and the download button appears only when decoding produced binary bytes.
Two pitfalls matter. First, decoding is strict on purpose: a string whose length is not a multiple of four, characters outside the 64-symbol alphabet, or padding in the wrong place is rejected with a reason instead of silently producing garbage. If you copied the string from a URL, remember that URL-safe variants drop the trailing equals signs — paste the full string, padding included. Second, decoded bytes are shown as text only when they are valid UTF-8. If you decode a Base64-encoded image, archive, or key file, the page tells you the bytes are not text and offers a Download button that saves them as a file named decoded.bin. Use that button — copying the on-screen placeholder would hand you corrupted data, because the text box cannot represent those bytes exactly, and the round trip would never restore the original.
Reading the results: stats, overhead, and limits
After encoding, the tool reports byte statistics: the input size in bytes, the output length in characters, and the overhead percentage. The classic expansion is four output characters per three input bytes — about 33 percent — so the word Hello (5 bytes) becomes SGVsbG8= (8 characters, 160 percent of the input). Text with non-ASCII characters — accents, emoji, Cyrillic — is encoded as UTF-8 bytes first, so the reported input size is the byte count, not the character count, and a round trip restores the original text exactly. After decoding text, the stats line shows how many decoded bytes were produced and confirms that they are valid UTF-8. For binary payloads it shows the byte count together with the notice that the bytes are not text and should be downloaded rather than copied, which keeps the size of the payload visible either way.
The size bars give a visual comparison of input and output — expect the output bar to run about a third longer than the input, which is the price of text-safe transport. The limits are honest ones: this tool uses the standard RFC 4648 alphabet with padding, so URL-safe variants and unpadded strings are not a separate mode, and files are processed in memory, which keeps the tool responsive but means it is not built for multi-gigabyte archives. Base64 is not encryption, so treat encoded output as readable by anyone who sees it — encode nothing you would not paste into a public chat. When decoding fails, read the error message: it names whether the length, the characters, or the padding is at fault, and that almost always points at a copy-paste problem rather than something wrong with the data.
¿Cómo se calcula el resultado?
Descodificar la sección de payload de un JWT
La sección central de un JWT es JSON codificado en Base64. Descodificarla aquí muestra el payload, pero esta herramienta solo descodifica: nunca verifica la firma. El contenido descodificado se muestra sin pretender autenticidad alguna, por eso la página avisa de que descodificar no es validar.
Entrada y resultado del ejemplo | Entrada | Valor |
| base64 | eyJ1c2VyIjogImFsaWNlIiwgInJvbGUiOiAiYWRtaW4ifQ== |
| Resultado | {"user": "alice", "role": "admin"} (sin verificar — descodificar no es autenticación) |
Encoding credentials for a Basic auth header
Your staging API is protected by HTTP Basic auth, and the runbook’s curl commands need an Authorization header of the form Basic <base64>. The credential pair is admin:live_Kx9mQ7d2 — pasting it into the header directly is invalid, because the scheme requires the pair to be Base64-encoded first. Type the pair into the tool’s input box, press Encode, and you get YWRtaW46bGl2ZV9LeDltUTdkMg==, with the stats line reading 19 bytes → 28 chars (147%) — the classic cost of making the pair text-safe. The analogy that keeps people honest: Base64 is packaging, not a lock. It puts the credential into a standard crate that every transport layer can carry, but the crate opens without a key, so the header is readable by anyone who intercepts it. That is why Basic auth is only ever used over HTTPS, and why you should treat the encoded string as carefully as the pair itself. Back in the runbook, the command becomes curl -H “Authorization: Basic YWRtaW46bGl2ZV9LeDltUTdkMg==” https://staging.example/api. Verify the request returns 200, and regenerate the value whenever the key rotates — the runbook should document that the header is a derived value, not a permanent secret. The stats line earns its place here too: 19 bytes → 28 chars (147 percent) means a header or config field with a length limit will take just over one and a half times the plain length of the pair, so you can predict whether the value fits before you paste it. If the server starts rejecting the header, decode the value here to confirm it still reads admin:live_Kx9mQ7d2 before you touch the server configuration, and note that the same flow applies to any username:password pair — the colon is the separator the scheme expects.
Entrada y resultado del ejemplo | Entrada | Valor |
| text | admin:live_Kx9mQ7d2 |
| Resultado | YWRtaW46bGl2ZV9LeDltUTdkMg== — 19 bytes → 28 chars (147%) |
A truncated string that fails strict validation
While reading a config file your colleague sent over chat, you find a Base64 string that should hold a hostname — but decoding fails with Invalid Base64: length is not a multiple of 4. The string reads SGVsb, which is a truncated form of SGVsbG8=, the encoding of Hello: somewhere in the copy-paste hop the last three characters were cut off. The strict decoder checks the shape before it trusts the content, the way a jigsaw puzzle lets you see a missing piece before you start assembling. Each group of four Base64 characters encodes exactly three bytes, so a string whose length leaves a remainder of one when divided by four can never be valid — a lone leftover character would hold fewer bits than the alphabet can represent. Instead of guessing, the tool refuses with a specific reason, and that message is the useful part: it names the length as the problem, which points at truncation rather than a wrong character or a bad paste. Paste the complete SGVsbG8= and the decode succeeds, showing Hello as valid UTF-8 text with a stats line of 5 decoded bytes. Base64 strings often end in one or two equals signs, and chat apps, terminals, and email clients have all been known to eat them — treat the padding as part of the data. This is the honest behavior of the tool: bad input produces a clear explanation, never silent garbage, which is the opposite of a lenient decoder that would return a shortened or scrambled result and leave you debugging a server against the wrong value.
Entrada y resultado del ejemplo | Entrada | Valor |
| base64 | SGVsb |
| Resultado | Invalid Base64: length is not a multiple of 4. |
Preguntas frecuentes
¿Base64 es cifrado?
No. Base64 es una codificación que hace que los datos binarios sean seguros para texto; no añade ningún secreto. Cualquiera que vea el texto codificado puede descodificarlo al instante. Nunca trates Base64 como una forma de proteger datos.
¿Por qué no puedo descodificar algunas cadenas de vuelta a texto?
Los bytes descodificados pueden no ser UTF-8 válido —por ejemplo, una imagen o un archivo comprimido codificados—. El descodificador lo detecta y ofrece los bytes como archivo descargable en lugar de corromperlos al convertirlos en texto.
¿Descodificar un JWT lo verifica?
No. Cualquier descodificador Base64 puede leer el payload de un JWT; la firma es lo que prueba la autenticidad, y verificarla requiere la clave del emisor. Un token descodificado no te dice nada sobre si es auténtico.
Can I encode a file, or only text?
Both. The file control reads a file from your device as bytes and encodes the whole thing into the input box, so you can encode a small PDF, an image, or a key file without opening it — the stats line shows the byte count and the resulting character count. Files are processed in memory, so the tool is designed for typical payloads rather than multi-gigabyte archives.
Does the tool accept Base64 with line breaks or spaces?
Yes. Whitespace — spaces, tabs, and line breaks — is stripped before validation, so a string wrapped across lines in an email or a terminal decodes correctly. Only whitespace is ignored: any other stray character, such as a quote mark or a hyphen, is rejected, because the strict check trusts only the 64 standard symbols and the equals-sign padding. If you are pasting from a message app, the line breaks are fine to leave in.
Why does my decode fail even though the string looks valid?
Three things are checked in order: the length must be a multiple of four (after stripping whitespace), every character must belong to the 64-symbol alphabet, and padding must sit only at the end. A string cut off mid-copy usually trips the length check; a stray dash or underscore trips the alphabet check — URL-safe Base64 uses those characters and is not supported here. The error message names the failing check, which tells you what to fix in the pasted string.