Base64 decode

Base64 Decode reads a Base64 string, turns its encoded symbols back into bytes, and decodes those bytes as UTF-8 text. Before decoding, it accepts the URL-safe substitutions by changing `-` to `+` and `_` to `/`. It also adds trailing equals signs until the length reaches a multiple of four. The displayed result is text, not a downloaded binary file.

The tool can therefore decode common standard Base64 and many unpadded Base64url text values. It does not validate a protocol wrapper, JWT signature, media type, or character encoding claim. If the recovered bytes represent JPEG data, a ZIP archive, or encrypted ciphertext rather than UTF-8, the text result may contain replacement characters and unreadable symbols.

Decoding reveals representation; it does not prove where the value came from or whether it is safe. Treat unknown output as untrusted input. Do not execute code, open generated links, or paste decoded markup into a privileged console merely because the Base64 conversion succeeded.

The input `aGVsbG8=` decodes to `hello`. The value `Y2Fmw6k=` decodes to `café` because its bytes form valid UTF-8. A URL-safe string containing `-` or `_` is normalized before the browser decodes it. Missing padding is added automatically, which helps with JWT-style sections and web values that omit equals signs.

Padding repair cannot fix arbitrary corruption. A forbidden symbol, misplaced character, or impossible Base64 length can make the browser's decoder throw an error. Copy the value without surrounding quotation marks, prefixes, or punctuation unless those characters belong to the encoded data. A JSON property such as `"data": "aGVsbG8="` requires only the value between the quotes.

The empty string decodes to empty text, though the workbench may simply show an empty result. Whitespace behavior can vary with the underlying browser decoder and surrounding copied content. For reliable debugging, remove line labels and confirm whether a protocol permits wrapped Base64 before assuming every space is harmless.

Identify the boundary of the encoded value first. In an authorization header, token, data URL, or email part, the Base64 text may be preceded by a scheme or metadata. Copy only the encoded segment. Paste it into the input and run Base64 Decode. Keep the original beside the result so you can trace exactly which fragment was inspected.

For an API field, compare the decoded text with the format promised by the API. If it should be JSON, parse the result with the JSON formatter rather than judging it by indentation. If it should be `username:password`, confirm that the colon appears in the expected place without sharing the credential. If it should be a UTF-8 message, check accented and non-Latin characters for replacement symbols.

Record a safe test vector when troubleshooting with another developer. Share a disposable encoded sample, the expected plain text, and whether the source uses standard Base64 or Base64url. Do not paste a live session token simply to reproduce a decoder issue.

Re-encode the decoded text and compare the result with a normalized form of the input. Standard and URL-safe alphabets, plus optional padding, can produce strings that differ visually while representing the same bytes. A direct character comparison may therefore fail even when the round trip is sound. Normalize according to the protocol before comparing.

Check byte-sensitive details. Leading spaces, trailing newlines, tab characters, null characters, and Unicode normalization can affect downstream parsing while remaining hard to see. Paste the decoded text into a hex-aware editor or write a small test in the application runtime when exact bytes matter. This browser result is intended for readable UTF-8 inspection, not a byte-by-byte forensic report.

If the result is JSON, a successful Base64 step does not guarantee valid JSON. Run it through JSON.parse or the JSON formatter. If it is a timestamp, validate units and time zone with the timestamp converter. Each layer has its own rules, and passing one layer says nothing about the next.

The underlying Base64 bytes may use a character set other than UTF-8, such as Windows-1252 or UTF-16. TextDecoder is used without a different encoding option, so this workbench always interprets bytes as UTF-8. Invalid sequences are normally replaced with the Unicode replacement character rather than exposed as raw byte values. Seeing diamond-shaped replacement symbols is a sign to verify the source encoding.

Binary content is another common cause. Base64 can represent any bytes, not only prose. PNG files often begin with a recognizable binary signature, compressed data has no readable sentence structure, and encrypted values should appear random. Use a file-aware decoder that writes raw bytes when the content type is binary. Copying unreadable text from this result cannot reconstruct the original file reliably.

Double encoding also creates confusing output. A decoded result may itself look like Base64 because the source was encoded twice. Decode a second time only when the producer's specification or a controlled test confirms that layering. Repeatedly decoding unknown input can turn ordinary text into errors and encourages guessing instead of identifying the data contract.

JWT header and payload sections use Base64url and usually omit padding. This decoder can recover the text of a section, but it does not split the token automatically and does not verify its signature. The JWT decoder is safer for inspection because it requires three dot-separated sections, parses header and payload JSON, and labels the signature as present but unverified.

A data URL begins with metadata such as `data:text/plain;base64,`. Do not include that prefix in the Base64 input. The media type tells a consumer how to interpret the bytes, while this tool always displays UTF-8 text. An image data URL needs a binary decoder or browser preview, not a text decoder.

MIME email parts may wrap Base64 across lines and include transfer-encoding headers. Separate the encoded body from its headers, and follow the mail format's line rules. Attachments are usually binary, so a text result will not be useful. Use a trusted mail client or file decoder for attachment recovery.

Decoding takes place locally in the open browser tab. PWRKIT does not receive the entered value or its decoded result for server-side processing. Both can still remain in clipboard history, session restoration, screen recordings, extensions, local monitoring, or any destination where you paste them. Base64 often contains credentials or tokens precisely because protocols represent bytes this way, so treat the input as sensitive until you know otherwise.

Never assume an encoded string is harmless. Decoded content can include script, HTML, shell commands, phishing links, or control characters. Read it as data. Do not run it, render it as trusted markup, or insert it into a database query without the validation and escaping required for that destination.

For production secrets, use an approved local tool or application debugger with masked logging. Create a test token or fake credential for shared troubleshooting. Clear both fields after inspection, then handle clipboard history and saved notes according to policy.

Base64 decoding answers one question: which bytes were represented by this string, interpreted here as UTF-8? JSON formatting answers whether resulting text follows JSON grammar and can reserialize consistently. JWT decoding separates token sections and parses two JSON objects, but still does not establish trust. Signature verification requires the correct algorithm, key, issuer rules, audience rules, and claim validation in an authentication library.

URL decoding handles percent escapes such as `%20`, not Base64 symbols. HTML unescaping reverses markup entities in a different grammar. Hashing cannot decode anything because a digest is one-way. Match the operation to the documented format instead of trying transformations until the output looks readable.

In application tests, keep examples for padded standard Base64, unpadded Base64url, multibyte UTF-8, empty input, malformed symbols, binary bytes, and trailing newlines. Automated tests in the production runtime are the final authority. The browser workbench is best for small inspections and for explaining a known conversion to another person.

Values are often copied from JSON, environment files, HTTP headers, terminal output, or database rows. Each container adds syntax that may not belong to the Base64 data. Remove JSON quotation marks, a `Basic ` or `Bearer ` scheme, a property name, and a trailing comma only after confirming the documented boundary of the value.

Shell output can wrap long values visually without inserting data, while copied terminal text can include real line breaks or prompts. Compare the copied length with the producer's value. If the system provides a raw-copy button, prefer it to selecting a wrapped display with the mouse.

A decoder error after copying from a URL may come from percent encoding. Characters such as equals signs can appear as `%3D`, and plus signs may be interpreted as spaces by form parsing. Apply URL decoding at the URL layer first, then Base64 decoding to the recovered parameter according to the API contract.

Do not silently strip every nonalphabet character. Aggressive cleanup can turn corrupt or tampered data into a different byte sequence that happens to decode. Preserve the original, document each wrapper removed, and reject unexplained characters in application code.

When a producer controls the value, fix output at that source. It should state whether the alphabet is standard or URL-safe, whether padding is present, what the decoded media type is, and which character encoding applies to text. A precise contract removes guesswork from every consumer.

For batch investigation, decode one value at a time and label the result outside the workbench with a nonsecret reference. Combining several encoded strings in one input creates bytes the producer never intended and can hide which record was malformed.