How to Convert a Base64 Block List into CSV, JSON, and SQL

You paste a column of Base64 blocks out of a secrets export, a log dump, or a support ticket, and the next thing you need is almost never that raw column. You need it as a JSON array for a fixture, a SQL IN clause for a one-off query, or a TypeScript union to constrain a type. Doing that by hand means adding quotes, commas, and brackets to every line and praying you did not fat-finger one. The Base64 Block List Converter does that reshaping in one step, in your browser, without sending the source text anywhere.

This post walks through exactly which formats the tool produces, why Base64 being case-sensitive matters here, and how a flat list becomes structured output you can drop into code or a database.

What the converter actually outputs

The tool reads each Base64 block from the same local parser and re-emits the whole set in whichever shape you pick. There are exactly six output formats:

Plain lines — one value per line, the cleaned-up version of what you pasted.
CSV — a column you can hand to a spreadsheet, a CRM import, or a script.
JSON — a JSON array of the values, ready for a fixture or a config file.
Markdown — a list or table you can drop into review docs and notes.
SQL IN — a comma-separated, quoted list for a WHERE col IN (...) clause.
TypeScript union — a string-literal union type built from the values.

On top of the format switch, you can keep unique rows only, sort the normalized output, and choose to carry invalid rows through with their reason so you can fix the source before re-running. None of that touches a server: parsing, validation, dedupe, copy, and download all run in the tab.

Why case-sensitivity is not optional

Base64 is case-significant. a and A are different symbols in the alphabet, and they decode to different bytes. That sounds obvious until a "helpful" cleanup step lowercases everything, or a case-insensitive dedupe silently merges aGVsbG8 and AGVSBG8 into one row. Now your JSON array is short one token, and the bug only shows up when something downstream fails to decode.

The converter preserves case exactly. When it dedupes, two blocks that differ only in case stay as two distinct rows, because for Base64 they genuinely are two distinct values. That is the kind of detail that does not matter until it ruins an afternoon, so the tool defaults to the safe behavior instead of the convenient one.

A worked example: list to JSON, list to SQL

Say you paste three blocks, one per line:

aGVsbG8=
d29ybGQ=
aGVsbG8=

With unique rows on, the duplicate aGVsbG8= collapses. Switch the format to JSON and you get:

["aGVsbG8=", "d29ybGQ="]

Switch the same input to SQL IN and the converter emits a clause you can paste straight after WHERE token IN:

('aGVsbG8=', 'd29ybGQ=')

Flip to TypeScript union and the values become a literal type:

"aGVsbG8=" | "d29ybGQ="

The point is that the input never changed — you pasted one flat list — and you walked away with three different artifacts without retyping a single character or hand-balancing a bracket. The case of every block came through untouched, so the JSON and the SQL carry exactly the bytes you started with.

Where this fits in real work

I reach for this most when I am stitching together a quick reproduction. A teammate sends a handful of tokens in a thread, I paste them into the converter, dedupe, sort, and export a JSON array straight into a test fixture. Five minutes later I need the same set as a SQL IN clause to check which of them still exist in a table, so I flip the format and copy again from the identical input. The thing I value is not any single conversion — it is that the source list stays the source of truth and every output is one click away from it. I never end up with a JSON array and a SQL clause that quietly disagree because I edited one and forgot the other.

A few habits make it smoother. Copied web text and email dumps often carry hidden whitespace, so normalize before you dedupe or import, otherwise two visually identical blocks refuse to merge. If you want an audit trail rather than just the final values, export CSV or Markdown with line numbers instead of copying only the cleaned list. And keep in mind that valid Base64 is a statement about format, not about reality: a block can be perfectly well-formed and still be a token that was revoked an hour ago.

Picking the right tool for the job

The converter is the multi-format end of a small family of single-purpose tools, and sometimes one of those is a better fit. If all you want is to standardize padding and whitespace across a messy list before doing anything else, the Base64 Block Normalizer does exactly that and nothing more. If your blocks are JWTs and you want to read the header and payload claims rather than reshape the list, the JWT Token Extractor is the one to open.

A reasonable flow is: extract or normalize first to get a clean, consistent list, then bring it into the converter when you need it as CSV, JSON, SQL, a TypeScript union, Markdown, or plain lines. Because each step runs locally, you can chain them on sensitive exports without any of the text leaving your machine.

Wrapping up

The job here is narrow and common: take a flat list of Base64 blocks and turn it into the structured shape your code or your database expects. This tool does that across six formats — lines, CSV, JSON, Markdown, SQL IN, and TypeScript union — keeps duplicates and case honest, and never uploads what you paste. Once it is part of your muscle memory, the manual quote-and-comma dance just stops being something you do.

Made by Toolora · Updated 2026-06-13