Card Number Converter
Paste a card UID in any form — 4-byte hex, 7-byte NFC, decimal, reversed or colon groups — and see every form at once, including HID Prox numbers.
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.
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.
Most converters hand you a number without saying which storage convention produced it. You then have two plausible numbers and no way to tell which one your panel expects — so you try both at the door.
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. HID Prox cards work the same way with one extra step: the H10301 26-bit format is administered by a 16-bit card number, and pasting that number here gives its hex form as a 4-byte UID — card number 12345 comes out as 00003039, where the last four digits are the 16-bit value a HID tool prints. The facility code and the parity bits that complete the 26-bit frame belong to the Wiegand converter, not to this page.
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.
Why do Hikvision and ZKTeco show different numbers for the same card?
Because two different things can disagree, and only one of them is byte order. The first is how the same four bytes are read — forwards or backwards — which is what the two decimals above show. The second is whether the system stores a raw UID at all: a panel that enrolled a 26-bit HID Prox credential stores a facility code plus a 16-bit card number, while another system reading the same credential may keep the four bytes as hex. Both numbers can be correct records of one card. Compare the form each system already stores, not which number looks more familiar. Which convention a given brand uses depends on the model, the firmware and how the installer enrolled the card, so no brand-wide rule is reliable — including this one.
I replaced the reader and the numbers still disagree. Why?
Because the format usually lives on the controller, not the reader. A reader sends raw bits over the Wiegand pair; the panel decides where the facility code stops and the card number begins. If the panel is set to a 26-bit layout while the credential is 34-bit, every read is internally consistent and still wrong — which is exactly what makes it hard to spot. Check the format on the controller before replacing any more hardware.
Why does one card open one door but not another?
Because each door is usually a separate record. Two systems can hold the same physical card under different numbers — one as a 26-bit facility code plus card number, one as a raw UID — and the access rule is attached to the record, not to the card. When a card works at one door and not another, compare the numbers the two systems have stored for it before re-enrolling. This page gives you every form of the same card so the comparison has something to match on.
Other tools
Guides
Why Card Number Formats Differ: Hex, Decimal, Byte Order
One reader prints 04A2243A, another prints 975479300 — and both are right. The four forms a card UID can take, and the step that quietly invents a number.
Wiegand 26 vs 34 Bit Format: The Facility Code Split
Both formats carry a facility code and a card number, but the boundary sits at a different bit. That is why one credential reads as two different people.