Why Tarot Birth Card Calculators Disagree — and How I Made the Math Visible

Christopher Shen — Sun, 13 Sep 2026 01:22:46 +0000

If you have tried more than one tarot birth card calculator, you may have noticed something confusing: the same birthday can produce different cards.

That is usually not a bug. Different calculators use different reduction methods, often without showing which one they chose.

One common example

For a birthday such as March 23, 1983, two methods may look like this:

Grouped year: 3 + 23 + 19 + 83 = 128, then 12 + 8 = 20, then 2 + 0 = 2.
Whole year: 3 + 23 + 1983 = 2009, then 2 + 0 + 0 + 9 = 11, then 1 + 1 = 2.

The first path gives Judgement (20) / The High Priestess (2). The second gives Justice (11) / The High Priestess (2).

Neither result can be understood properly unless the calculator explains its method.

The method I used

I built a small browser-based calculator using the Tarot School pair method:

Split the year into century and year remainder.
Add month + day + century + remainder.
Reduce the total according to the method's grouped rules.
Preserve the special 19 → 10 → 1 three-card sequence.
Show every calculation step beside the result.

The main design goal was not to claim that one tradition is universally correct. It was to make the chosen convention explicit, so people can understand why another site might give a different answer.

A few product decisions

The birth date is calculated in the browser and is not placed in the URL.
The result is framed as a reflection prompt, not a prediction or personality diagnosis.
The calculator shows both the card pair and the arithmetic behind it.
Each supported pair has a dedicated explanation page.

You can try the calculator here:

Tarot Birth Card Calculator

If you test it, I would especially like to know whether the visible calculation resolves the “why did another calculator give me different cards?” problem.

What I Learned Building a Browser-Only Credit Card Test Data Generator

Christopher Shen — Sun, 30 Aug 2026 14:10:45 +0000

What I Learned Building a Browser-Only Credit Card Test Data Generator

Payment-form testing often begins with a surprisingly small problem: a random string of digits usually fails before the form can test anything else. The field may expect a known card-network prefix, a particular length, and a valid Luhn check digit. A tester may also need an expiry date and a three- or four-digit security code just to exercise the interface.

I built a small browser-only generator to make that test data available without an account, a database, or a server-side API. The project also clarified an important boundary: a structurally valid card number is not the same thing as a card that can complete a payment.

What “Luhn valid” actually means

The Luhn algorithm is a checksum. It helps software catch common input mistakes, but it does not prove that an account exists or that a transaction will be authorised.

To calculate the final check digit, the generator:

Starts with a card-network prefix.
Adds random digits until the number is one digit short of the required length.
Processes the digits from right to left, doubling every second digit and subtracting nine when the result is greater than nine.
Chooses a final digit that makes the total divisible by ten.

The resulting number can pass a basic Luhn validator. It still has no bank account, balance, issuer relationship, or payment capability behind it.

Card networks are not all formatted the same way

The generator uses a deliberately small set of common test profiles:

Card type	Test prefix used	Number length	Security-code length
Visa	4	16	3
Mastercard	51–55	16	3
American Express	34 or 37	15	4
Discover	6011	16	3
JCB	3528–3589	16	3
UnionPay	62	16	3
Diners Club	36	14	3

These profiles are useful for front-end and validation tests, but they are not an exhaustive representation of every range used by each network. A production payment integration should be tested with the official sandbox data supplied by its payment provider.

Why generate the data in the browser?

The most useful privacy decision was also the simplest architectural decision: generate everything locally.

The tool does not need to send generated card numbers, names, security codes, or expiry dates to a server. That removes the need for a storage layer and reduces the chance of test data appearing in logs. It also keeps the core workflow fast: select a card type, choose a quantity, and generate.

The same rule applies to analytics. It is useful to know whether someone generated a batch, copied a number, exported JSON, or downloaded CSV. It is not useful—or appropriate—to send the generated values themselves. The analytics events therefore contain only an action name plus a non-sensitive card type or batch count.

Batch output matters more than a decorative card

A visual card can be helpful for demos, but repeated form testing needs compact output. I prioritised:

One to twenty records per batch.
A copy button beside each card number.
JSON copying for test fixtures and API examples.
CSV download for spreadsheets and data-driven test runs.
Responsive output that remains usable on both desktop and mobile.

This is still a small tool, but those choices make it more useful than returning a single unformatted number.

Turning one generated card into four test cases

The latest version adds a small QA test pack. After generating a card, the tool uses the first record to create four client-side payment-form cases:

A structurally valid card record.
The same record with a broken Luhn check digit.
The same record with an expiry date in the past.
The same record with a CVV or CID of the wrong length.

Each case includes its purpose, input values, and expected result. A tester can copy the pack as a step-by-step Markdown plan for an AI coding tool or manual QA session, or download the same cases as structured JSON for Playwright, Cypress, or another test setup.

This does not make the generator a payment simulator. It turns one synthetic record into a reusable validation checklist, while transaction approvals, declines, 3-D Secure, and other provider behaviour still belong in the payment provider's official sandbox.

What this kind of generator cannot test

Synthetic Luhn-valid data can help with:

Field formatting and masking.
Card-type detection.
Required-field and length validation.
Responsive checkout layouts.
Demo data, documentation, and QA fixtures.

It cannot test issuer approval, balances, 3-D Secure, address verification, fraud decisions, payment-provider responses, or a live transaction. Those behaviours require the official sandbox or test mode of the payment service being integrated.

Try the tool

The finished MVP is available at Random Credit Card Generator. It is free, requires no sign-in, generates the card-shaped test data locally in the browser, and can turn the first generated card into a four-case QA test pack.

I am still treating it as an experiment. If you test payment forms or build QA fixtures, I would be interested in which output format or validation case would save you the most time.

DEV Community: Christopher Shen

Why Tarot Birth Card Calculators Disagree — and How I Made the Math Visible

One common example

The method I used

A few product decisions

What I Learned Building a Browser-Only Credit Card Test Data Generator

What I Learned Building a Browser-Only Credit Card Test Data Generator

What “Luhn valid” actually means

Card networks are not all formatted the same way

Why generate the data in the browser?

Batch output matters more than a decorative card

Turning one generated card into four test cases

What this kind of generator cannot test

Try the tool