Hong Kong ID check digit
The body A123456 gets the check digit 3, so the full Hong Kong ID reads A123456(3). Calculate that last character, or check a full number before saving a profile or accepting a form, and catch typing slips such as A123456(4). Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Hkid
- A123456
- Calculation mode
- Compute
- Input
- A123456
- Check digit
- 3
- With check
- A1234563
- Formatted
- A123456(3)
Hong Kong identity card numbers end with a single check character derived from a fixed modulo-eleven weighting of the prefix letters and the six body digits. That trailing character is either a digit zero through nine or the letter A, and it is usually printed in parentheses after the body — for example A123456(3) or G123456(A). A mistyped letter, a swapped body digit, or an OCR slip on a form often breaks the checksum, so validating the check digit before saving a profile, accepting a KYC document, or importing a roster catches many keying errors early. This capability computes the Hong Kong ID check digit for a one- or two-letter prefix plus six digits, or validates a full number that already includes the trailing character, and it reports bad input instead of silently stripping punctuation.
What the Hong Kong ID check digit is and how the modulo-eleven weights work
A Hong Kong permanent or non-permanent identity card number is built from one or two alphabetic prefix characters, six decimal digits that form the body, and a final check character. The Immigration Department scheme maps each letter to a number (A equals ten, B eleven, through Z equals thirty-five) and, when the card uses a single letter prefix, inserts a leading space valued at thirty-six so every sum always covers eight positions.
Those eight values are multiplied by the fixed weights nine, eight, seven, six, five, four, three, and two from left to right. The products are added, the total is reduced modulo eleven, and eleven minus that remainder becomes the check: if the result is eleven the printed character is zero; if it is ten the printed character is the letter A; otherwise the result itself is the decimal check digit. When someone types A123456(3) as A123456(4), the weighted sum no longer matches and validation fails.
The same rule catches many single-character substitutions in HR onboarding, bank KYC packs, telecom subscriber forms, and school registration files where operators re-key numbers from plastic cards or passport scans. This tool implements that public weighting on normalized uppercase letters and digits after optional space and parenthesis handling. It does not query any government database, prove that a person exists, or decode age or residency status from the body — only that the character string is consistent under the published check algorithm.
Compared with Luhn mod-ten used on payment cards, the HKID scheme uses letter values and modulo eleven with an A sentinel, so you must not reuse a Luhn validator on Hong Kong ID fields. Compared with mainland Chinese resident ID or Macao ID helpers, the Hong Kong rule is specific to this one- or two-letter prefix, six-digit body, and eight-position weight vector. Knowing which scheme you need avoids false confidence when a general check-digit utility accepts a digit string that is not a well-formed Hong Kong identity card number.
Where Hong Kong ID check digits fit KYC, HR, and commercial workflows
Know-your-customer and account-opening flows in banks, brokers, and fintech apps store a Hong Kong identity card number on every eligible resident profile; a single mistyped digit during onboarding can send compliance documents to the wrong person or fail a later match against a document scan. Employers, schools, and telecom operators attach an HKID to each person in batch CSV imports; off-by-one body errors and missing parentheses are common when data is re-typed from paper, and a check digit catches them before the first payroll or SIM activation run.
Product teams that already expose general Luhn or ISO 7064 check tools should still use this Hong Kong-specific capability for HKID fields so letter mapping, single-letter space padding, length bounds, and A-as-ten formatting match the domain. Do not treat a passing Hong Kong ID check digit as proof that the person is correctly identified, holds a valid card, is a resident, or appears in any official registry — it only proves the character string is consistent under the Hong Kong identity card modulo-eleven check algorithm.
What you can do with it
Audit Hong Kong ID columns in partner and payroll files
Batch-validate every HKID in a CSV import and quarantine rows whose check character no longer matches the recomputed expected value.
FAQ
What happens with wrong length, letters, or punctuation?
Provide 1–2 letters and six digits, optionally a check 0–9 or A. Compute needs the body only; validate needs the full ID. Failed validation tasks are not billed.
Is the Hong Kong ID check digit tool free?
The browser tool is free and runs locally.
How is the Hong Kong ID check digit calculated?
Letters become numbers (A is 10, Z is 35) and a single-letter prefix gets a leading space worth 36. The eight values are multiplied by 9 down to 2 and added; 11 minus the remainder after dividing by 11 is the check, with 10 written as A and 11 as 0.
Why do some Hong Kong ID numbers end in A?
When the calculation gives 10, the check character is written as the letter A instead of a two-digit number, as in G123456(A). Every other result is printed as a single digit.
Does a valid check digit prove the ID card is real?
No. It only shows that the characters are consistent with the published check rule. No government database is consulted, and the tool does not reveal age, residency status or whether the person exists.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/enc/hkid \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"hkid":"A123456"}'const res = await fetch("https://api.kit.forhosting.com/enc/hkid", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"hkid": "A123456"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/hkid",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"hkid": "A123456"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/hkid", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"hkid":"A123456"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"hkid":"A123456"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/hkid", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"hkid": "A123456"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.hkid",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Use it free in the browser or call the KIT API at the published price; both paths run the same deterministic arithmetic with no network lookup and no registry of real cardholders.
How to compute a check digit or validate a full Hong Kong ID
Send an hkid field that contains one or two letters A through Z, six digits zero through nine, and optionally a trailing check character zero through nine or A. Mode validate expects a complete number including the trailing check character, either in parentheses (A123456(3), G123456(A)) or attached as a final character (A1234563, G123456A). Empty strings, missing hkid, invalid mode values, wrong letter or digit counts, and compute requests that already include a check character fail before any weighted sum runs and are not billed. Spaces around the value are trimmed; other punctuation, lowercase (normalized to uppercase), double parentheses, or embedded symbols are rejected as malformed input with invalid_input so you never accept a silently cleaned value. Mode compute is the default: provide the body only without the check character (for example A123456, G123456, or XA123456), and the engine returns check_digit as a one-character string, with_check as the body plus that character without parentheses, and formatted as the familiar BODY(CHECK) form used on cards and forms. The response reports valid true when the recomputed check character matches the supplied one, and always includes check_digit, expected_check_digit, body without the check, with_check, and formatted for consistent display. Because the path is pure parse with no clock, random source, or network, the same input always yields the same JSON on the free browser tool and on the API. At $0.002 per successful request you can gate bulk roster imports, onboarding forms, and ETL jobs without negotiating a custom tier. Prefer compute when you assemble an ID string from a known prefix and six-digit body; prefer validate when a user, partner file, or scanned card supplies a full number and you need a boolean gate before an internal master-data lookup.
Where Hong Kong ID check digits fit KYC, HR, and commercial workflows
Validate mode at entry blocks the save when valid is false and can show expected_check_digit so the clerk corrects the form before the record is written.
Integration use cases
Gate HKID fields on onboarding and KYC forms
When a user submits a full Hong Kong ID, call validate mode and block the save when valid is false, showing expected_check_digit to help correct a single mistype before the profile is written.
Compute check digits when completing ID strings
From a letter prefix and six-digit body, call compute mode and store with_check or formatted so every new HKID-like string carries the correct trailing character before print or export.
Technical questions
What is the Hong Kong ID check digit?
It is a single trailing character (0–9 or A) computed with weights 9..2 over letter values (A=10..Z=35, leading space=36 for one-letter prefixes) and six body digits, then modulo 11, so most single-character typos break the checksum.
How do I compute a Hong Kong ID check digit with this API?
POST with hkid set to the body only (one or two letters plus six digits, e.g. A123456) and mode compute (or omit mode). The response includes check_digit, with_check, and formatted as BODY(CHECK).
How do I validate a full Hong Kong ID?
POST with the full number including the check character (e.g. A123456(3) or G123456(A)) and mode validate. The response includes valid, check_digit, expected_check_digit, body, and formatted.