Skip to main content

Convert a Card Number List Into JSON, SQL IN, or a TypeScript Union for QA Fixtures

Turn a list of test card-shaped numbers into CSV, JSON, SQL IN, or TypeScript union output for QA fixtures. Values stay masked in the output. Runs fully in your browser.

Published By Li Lei
#test data #qa fixtures #credit card #json #sql

Convert a Card Number List Into JSON, SQL IN, or a TypeScript Union

If you write tests for anything that touches payments, you end up with a scratch file full of card-shaped numbers. Not real customer cards: the canonical test PANs every gateway publishes, plus a few you generated to exercise Luhn checks and BIN ranges. The numbers are fine. The friction is shape. Your seed script wants a JSON array. Your database fixture wants a SQL IN (...) clause. Your TypeScript mock wants a string union. And the list you have is one number per line, copied out of a wiki page or a support thread.

The Credit Card Number List Converter exists for exactly that last-mile reshaping. You paste the list, pick an output format, and it re-emits the same set of numbers as line, CSV, JSON, Markdown, SQL IN, or TypeScript union. One detail to set expectations up front: because card numbers are a sensitive profile, the values are masked in the output. You get the structure and the validation signal, not a clean spreadsheet of full PANs. That is a deliberate guardrail, and below I'll be specific about what it means for fixtures.

What it actually does

The parser reads each card number out of whatever you paste, then hands the same list to a formatter. The same local engine drives every format, so switching from JSON to SQL IN is a single toggle, not a re-parse. Concretely, the tool can:

  • Extract card-shaped numbers from pasted text, logs, CSV exports, copied HTML, support tickets, and Markdown notes, or from a local text file you load.
  • Validate each number with a Luhn check and surface a reason when something fails.
  • Keep unique rows only, or preserve invalid rows beside their reason so you can fix the source first.
  • Sort the normalized output.
  • Emit line, CSV, JSON, Markdown, SQL IN, or TypeScript union.
  • Copy or download the exact artifact.

Everything runs in the browser. The list you paste, the file you load, and every transform happen in the tab. Nothing is sent to a server, which is the right default for anything card-shaped even when it is only test data.

The masking behavior, stated exactly

Here is the part that changes how you use the output, quoted straight from the tool's own behavior: sensitive profiles such as cards and JWTs mask values in the output while still giving you useful validation signals. The FAQ puts it plainly too: "Values stay masked in the output." So when you convert a card list to JSON, you are not getting an array of full sixteen-digit strings. You are getting a masked, structured representation plus the validity and reason fields the validator produced.

For QA work that distinction is usually a feature, not a limitation. If you are checking that your fixture loader handles N rows, that duplicates collapse, that invalid Luhn entries are flagged, and that the output is well-formed JSON or a syntactically valid SQL IN list, the masked form tells you all of that. If your test genuinely needs the full digits inline, generate them at fixture-build time from a documented test-card source instead of pasting full PANs through any web tool. The masking keeps you honest about that boundary.

A worked example

Say a teammate hands you four lines from a payments QA sheet. Two are duplicates, one fails Luhn:

4111 1111 1111 1111
4111 1111 1111 1111
5500 0000 0000 0004
1234 5678 9012 3456

Paste that, turn on "unique," and pick JSON. The converter normalizes the spacing, drops the duplicate, runs Luhn on each, and emits a JSON array of row objects: each row carries its masked value, line number, a valid boolean, and a reason. The first three collapse to two unique valid rows; 1234 5678 9012 3456 comes through marked invalid with its Luhn reason rather than being silently dropped, so you can go fix the source column. The masked values mean the array is safe to drop into a review doc or a ticket without smearing full numbers across it.

Now flip the same list to SQL IN. Without retyping anything you get a list shaped like:

... WHERE card IN (
  '4111…1111',
  '5500…0004'
)

ready to paste into the seed statement for a payments test fixture. Switch once more to TypeScript union and the same set becomes a '…' | '…' string-union type for a mock. Three formats, one parse, no hand-adding quotes and commas and missing exactly one of them at 6pm.

Why I built the workflow around this

I spend a lot of time seeding test databases, and the dumbest recurring tax was format conversion. I had a personal snippet that turned a newline list into a SQL IN clause, another half-remembered JSON.stringify one-liner, and a habit of forgetting the trailing-comma rule in TypeScript unions. Each one was thirty seconds and a coin flip on whether I'd typo it. Putting line, CSV, JSON, Markdown, SQL IN, and TypeScript union behind one parser with a dedupe toggle and a validity column removed an entire class of "the fixture didn't load because of a stray comma" debugging sessions. The masking nudged me toward a cleaner habit too: my fixtures now reference test cards by a documented source and build the full digits at generation time, while the converter handles the structure. The structure was always the boring part. Now it's a toggle.

Responsible use

This is a tool for test data and QA fixtures, not for collecting, storing, or moving real cardholder data. A Luhn pass means a number is well-formed; it is not proof that an account exists, and it is certainly not permission to handle someone's actual card. Keep real PANs out of any browser tool, this one included, and lean on the masking as a reminder of that line. If you need full digits for a test, generate them from a published test-card set at fixture-build time. The privacy posture here is local-only: parsing, validation, dedupe, copy, and download all happen in your tab, and loaded files are read with the File API and never uploaded. That keeps your scratch list yours, but it does not turn card data into ordinary text. Treat the output with the same care you'd give any payments fixture.

Where it fits

If your job is narrower than full conversion, the related single-purpose tools are leaner: the Credit Card Number Extractor pulls card-shaped tokens out of messy text, the Credit Card Number List Validator focuses on the Luhn-and-reason pass, and the Credit Card Number Deduplicator just collapses repeats. The list converter is the one to reach for when you have a clean-ish list and the only thing standing between you and a working fixture is the shape of the output.

Made by Toolora · Updated 2026-06-13