Card Number Converter

Paste a card UID in any of the forms it turns up in — decimal, big-endian hex, little-endian hex, reversed decimal or colon groups — and get every form of that same card at once, for 4-byte and 7-byte UIDs alike.

Every form is accepted — big-endian hex, little-endian hex, decimal, reversed decimal, colon groups — for 4-byte and 7-byte UIDs. Paste a column and every row is converted at once.

Table options — only used when you paste a table

Auto-detect reads an all-digit value as decimal, because the very same digits are also a valid hex UID (55667788 is either 0x03516C4C or the bytes 55 66 77 88). Pick hexadecimal when your reader gave you hex. Colon groups (55:66:77:88) are always hexadecimal.

Tables only (a pasted column, .csv, .txt or .xlsx). Auto-detect needs at least 3 samples and an 80% hit rate; below that the tool asks you to pick the column yourself.

When you need this

  • A reader hands you an 8-character hex UID and the access-control backend wants a 10-digit decimal card number — and you have to be sure they are the same card.
  • Two systems report different numbers for one card, and you suspect that one of them reads the bytes backwards.
  • You exported a column of card numbers from Excel and need each one in the form the other system expects.
  • You are commissioning a reader and want to confirm that the decimal, the hex and the colon-grouped value in the manual all describe the same card.

Why other card-number tools fall short

Most converters only swap endianness. They assume you already know which form you are holding — and that is precisely the thing that is unclear in the field.

They show a single result, so you cannot see that the decimal and the reversed decimal describe one card. People then try both numbers on the door, and one of them is wrong.

Given a 7-byte UID, or a value above 0xFFFFFFFF, they quietly truncate to 32 bits and hand back a plausible-looking card number that will never open anything.

The card column in a spreadsheet often carries thousands separators, and a converter that does not say which row it rejected leaves you to guess.

Frequently asked questions

Why does the same card give two different decimal numbers?

Because a 4-byte UID can be read as an integer in two directions. AABBCCDD read forwards is 2864434397; read backwards it is 3721182122. Both are correct readings of the same card — different backends simply picked different conventions. This tool lists both side by side and labels how each one was read, so you can match the number your system expects instead of trying both.

Which form should I give the access-control system?

Look at what it already stores. A 10-digit number in the 2.8 to 4.2 billion range is a 4-byte UID read as an integer. An 8-character string containing letters is the same bytes written as hex. Groups separated by colons are those bytes again. If the field is numeric, use one of the two decimals; if it is a string, the hex or the colon-grouped form is usually what the reader SDK expects. One case is genuinely ambiguous: an 8-digit value with no letters (55667788) is both a valid decimal card number and a valid hex UID. Auto-detect reads it as decimal — switch the Input form control to Hexadecimal when your reader gave you hex, or write it as colon groups (55:66:77:88), which is never ambiguous.

Can I paste a whole column from Excel?

Yes. Select the column, copy it, and paste — the clipboard carries tab-separated text, so every row becomes one card. Rows that cannot be read stay in the table instead of disappearing, and the export button gives you the whole result as CSV to paste back into the other system.

Why does it refuse a 7-byte UID written as a decimal?

A 7-byte UID is 56 bits, far beyond the 32-bit range a decimal card number can express. A 17-digit number in that field could be a 7-byte UID or an unrelated record number from another system, and nothing in the value tells the two apart. Rather than guess and hand you a card number that fails at the door, the tool says so and asks for the value as hex or as colon groups — every other form then follows from those bytes.

Why is a value like FFFFFFFF shown as if nothing changed?

Because nothing does change, and that is the correct answer. FFFFFFFF reads the same forwards and backwards, so the big-endian and little-endian forms, and both decimals, are identical. The tool states that explicitly, because a table whose rows all look the same is otherwise easy to mistake for a failure.

Is my card data uploaded anywhere?

No. The conversion is arithmetic on the bytes you pasted, and there is no backend to send anything to. Open the DevTools Network panel and convert a column: no request is made. The page installs as a PWA, so once it has loaded it keeps working with the network disconnected.

Other tools