Skip to main content

How to Validate Base64 Blocks in a Pasted List Without Decoding Every Line

Validate Base64 blocks from a pasted list: check the A-Z a-z 0-9 + / alphabet, padding, and length, and flag bad characters or misplaced = with a reason.

Published By Li Lei
#base64 #validation #encoding #developer-tools

How to Validate Base64 Blocks in a Pasted List Without Decoding Every Line

A list of Base64 strings looks tidy until one row refuses to decode. A pasted TLS config, a token vault export, a column copied out of a CSV — they all carry the same risk: one block with a stray space, an illegal character, or a = in the wrong place, and the import that consumes the list throws halfway through. The fix is not to decode every row by hand. It is to validate the format first, so you know which rows are sound and which ones need a second look, before the data goes anywhere.

That is exactly what the Base64 Block List Validator does: it reads a list of Base64 blocks from pasted text or an uploaded local file, checks each one against the rules of standard Base64, and prints a pass/fail report with a reason beside every row.

What "valid Base64" actually means

Standard Base64 has a small, strict rulebook, and almost every real-world failure comes from breaking one of three parts of it.

  • The alphabet. Valid standard Base64 uses only the 64 characters A-Z, a-z, 0-9, plus + and /. Nothing else. A comma, a space inside the block, a smart quote pasted from a document, an emoji glued to the end — any of those make the row invalid.
  • The padding. The = character is padding, and it is only ever allowed at the very end of a block. You will see zero, one, or two = signs, never more, and never in the middle. A = floating in the body of a string is a giveaway that two blocks were concatenated or a newline got eaten.
  • The length. A well-formed Base64 block has a total length that is a multiple of 4. Because each group of four characters encodes three bytes, anything that does not land on a multiple of 4 means characters were dropped, added, or wrapped wrong.

So a row like SGVsbG8gd29ybGQ= passes — clean alphabet, one trailing =, length 16. A row like SGVsbG8 d29ybGQ= fails on the space, and SGVs=bG8gd29ybGQ= fails on the misplaced =.

What this tool checks (and what it tolerates)

The Base64 Block List Validator runs a dedicated Base64 parser in your browser tab and checks each block one row at a time. When a block has a bad character or broken padding, the parser flags it and writes the reason next to it, so the report tells you exactly which line failed and why. An invalid block, in this tool's words, is one whose padding or alphabet does not decode cleanly — and that failing row stays in the list, by design, with its rejection reason attached.

A few things worth knowing about how it behaves:

  • Everything is local. Whether you paste from a config file or upload a .txt export, the blocks are validated inside the browser tab and never sent to a server. The File API reads uploaded files locally.
  • You control the output. You can keep only unique rows, keep invalid rows for review, sort the normalized output, and switch the report between CSV, JSON, Markdown, SQL IN, TypeScript union, and plain lines. Then you download the exact artifact your workflow needs.
  • Sensitive values get masked. For profiles like cards and JWTs, the tool masks the value in the output while still giving you the validation signal — so you can prove a row is well-formed without copying the secret around.

One practical note from the manifest's own guidance: copied web text often carries hidden whitespace, so it is worth normalizing before you deduplicate or import. Format validity is also not proof that an account, domain, or resource exists — a string can be perfectly valid Base64 and still point at nothing.

A worked example

Say a teammate hands you this list, pulled from a support ticket, and asks whether it is safe to import:

SGVsbG8gd29ybGQ=
dG9vbG9yYQ==
SGVsbG8 d29ybGQ=
YWJjZGVmZw
Zm9vYmFy*

Run it through the validator and the report comes back row by row, something like:

| line | block | valid | reason | |------|-------------------|-------|-------------------------------| | 1 | SGVsbG8gd29ybGQ= | true | OK | | 2 | dG9vbG9yYQ== | true | OK | | 3 | SGVsbG8 d29ybGQ= | false | illegal character (space) | | 4 | YWJjZGVmZw | false | length not a multiple of 4 | | 5 | Zm9vYmFy* | false | illegal character (*) |

Two rows pass. Row 3 has a space in the middle of the block. Row 4 is ten characters long, which is not a multiple of 4, so it is missing padding or lost a character. Row 5 carries a * that is not in the Base64 alphabet. Now you can hand back the clean two and ask about the three flagged rows instead of debugging a failed import after the fact.

Cleaning the list, not just judging it

Validation is the first half of the job; the second half is turning a messy paste into something you can actually use. Because the parser, the deduplicator, and the exporters all share the same engine, the same paste can be checked, deduped, sorted, and exported in one pass. Keep the unique rows for an allowlist, or keep the invalid rows together so a reviewer can see every rejection reason in a single Markdown table with line numbers. When you need an audit trail, download the CSV or Markdown with line numbers rather than copying only the final list — the reasons travel with the data.

If your job is less "is this valid" and more "give me a clean list," the Base64 Block List Converter shares the same workflow and focuses on the conversion and formatting side.

My own reason for building this

I reach for this most often when I am reviewing a config someone pasted into a chat. Someone drops a block of certificate or token text, I copy it into the validator, and within a second I can see whether every line is well-formed or whether line 14 has a trailing space that will blow up at deploy time. Before I had it, I was decoding strings by hand in a console, which is slow and tells you nothing useful when a row is malformed — the decoder just errors out. Seeing a row labeled false: illegal character next to the exact line is a much faster way to find the one bad block in a list of fifty, and it keeps the source text inside my own tab the whole time.

When to use it

Run a list through the validator before any step that will choke on a bad row: an import into a CRM or ticket system, an allowlist, a redirect map, a release note, or a compliance review. It is comfortable with a few megabytes of Base64 rows from an export; for a giant audit dump, split it locally first and check the pieces. The goal is simple — never let a malformed Base64 block reach the system that has to decode it.

Made by Toolora · Updated 2026-06-13