ISO 7064 check digit
With MOD 11-2, the code 0794 gets the check character 0, so the full identifier is 07940. Add the check character to a numeric or alphanumeric code, or verify a complete one and see which character was expected. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- 0794
- System
- mod11-2
- Calculation mode
- Compute
- Input
- 0794
- Check character
- 0
- With check
- 07940
- Length
- 5
ISO/IEC 7064 defines pure check-character systems that protect identifiers against single-character substitutions and many transposition and shift errors. MOD 11-2 covers pure numeric strings and may emit a trailing X when value ten is required; MOD 37-2 covers uppercase alphanumeric strings and may emit a trailing asterisk when value thirty-six is required. Both systems use modulus and radix two in a single left-to-right walk that ends at remainder one when the full string is well formed.
What ISO 7064 MOD 11-2 and MOD 37-2 protect
Check characters exist because people, scanners, and keyboards damage identifiers in predictable ways: one wrong symbol, two neighboring symbols swapped, a digit inserted or dropped, or a short circular shift of a fixed field. ISO/IEC 7064 standardizes several pure and hybrid systems so that industries can share one mathematical contract instead of inventing house checksums. The two single-character pure systems exposed here are MOD 11-2 and MOD 37-2.
MOD 11-2 maps digits zero through nine to values zero through nine and allows a supplemental check character X with value ten; it is the scheme used by ORCID identifiers and by many numeric reference codes that need a stronger guarantee than a plain modulo-ten digit. Both systems use radix two: the engine walks left to right, folding each character value with p equals two times p plus the character value, reduced modulo eleven or thirty-seven, and a well-formed full string always ends at remainder one.
That algebraic shape detects all single substitutions and a high rate of adjacent transpositions and other local errors without requiring a large lookup table. This tool implements those two pure systems only; it does not claim hybrid MOD 11,10 or MOD 37,36 behavior, and it names the algorithm in the response so downstream systems can record which scheme protected the value.
Where ISO 7064 check characters fit real systems
Research and scholarly platforms that mint or accept ORCID-style numeric identifiers can recompute or verify the trailing MOD 11-2 character before storing a profile link, catching a single mistyped digit at the form boundary. Manufacturers and logistics teams that print alphanumeric asset or carton codes can adopt MOD 37-2 so handheld scanners and call-center agents do not silently route work to the wrong SKU when two neighboring characters swap.
Healthcare, education, and government offices that still move paper forms with multi-character reference numbers can validate on entry and show the expected check character for a quick correction instead of creating a duplicate chart or case. Integration tests and data-quality jobs recompute the expected check character for every row in a CSV export and flag rows where the stored full string no longer matches, which catches both human edits and off-by-one bugs in generators.
Do not treat a passing ISO 7064 check as proof of authorization or ownership — it only proves the string is well formed under the chosen pure system, the same honesty bar you apply to any checksum.
What you can do with it
Audit exported ID columns
Batch-validate every identifier in a partner CSV or warehouse export under MOD 11-2 or MOD 37-2 and quarantine rows whose check character no longer matches the recomputed expected value.
FAQ
What is an ISO 7064 check character?
It is a trailing character defined by ISO/IEC 7064 so that a pure modular walk over the full identifier ends at remainder one, detecting single substitutions and many transposition errors.
Is the ISO 7064 check digit tool free?
The browser tool is free and runs locally.
When should I use MOD 11-2 and when MOD 37-2?
Use MOD 11-2 for identifiers made only of digits, such as ORCID-style numbers; its check can be X. Use MOD 37-2 when letters A to Z are part of the code, as on asset tags or product codes; its check can be an asterisk.
Why is the check character sometimes X or an asterisk?
Because the check can need a value one step beyond the normal symbols. In MOD 11-2 the value ten is written X; in MOD 37-2, where digits and letters cover zero to thirty-five, the value thirty-six is written as an asterisk.
Can I check an ORCID iD with this tool?
Yes, ORCID identifiers use MOD 11-2. Hyphens and spaces are removed first, so you can paste the grouped form, and the last character, a digit or X, is compared with the expected check character.
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/iso7064 \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"0794"}'const res = await fetch("https://api.kit.forhosting.com/enc/iso7064", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "0794"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/iso7064",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "0794"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/iso7064", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"0794"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"0794"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/iso7064", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"text": "0794"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.iso7064",
"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
This capability computes that trailing character for a payload you already have, or validates a complete identifier that already includes one, and it rejects characters outside the chosen alphabet with a clear invalid_input error instead of silently stripping garbage. The same pure arithmetic powers the free browser tool and the KIT API path, so goldens, ORCID-style checks, warehouse codes, and batch audits never disagree on a digit.
What ISO 7064 MOD 11-2 and MOD 37-2 protect
MOD 37-2 maps digits and uppercase letters A through Z to values zero through thirty-five and allows a supplemental check character asterisk with value thirty-six; it is suitable for product codes, asset tags, and mixed alphanumeric series where letters are part of the payload.
How to compute a check character or validate a full identifier
Send a text field with the identifier. Hyphens and spaces are stripped and letters are uppercased so ORCID-style groups and spaced labels still parse; every remaining character must belong to the alphabet of the chosen system. Empty strings, missing text, characters outside the alphabet, and invalid mode or system values fail before the modular walk finishes and are not billed. System defaults to mod11-2 for numeric work; set system to mod37-2 for alphanumeric payloads. Mode compute is the default: the engine walks the payload, returns check_character as a single character string, and returns with_check as the payload plus that character so you can store or print one string. Mode validate expects a full string of at least two characters, payload plus trailing check. The response reports valid true when the full walk ends at remainder one, and always includes the observed check_character, expected_check_character recomputed from the payload alone, and the payload substring without the last character. That shape makes it easy to show you typed X, expected Y in a form without a second call. 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 protect bulk imports, onboarding forms, and batch label printers without negotiating a custom tier. Prefer compute when you mint new IDs; prefer validate when you receive an ID from a user, a partner file, or a scanned label and need a boolean gate before looking up the record.
Where ISO 7064 check characters fit real systems
Product teams that already use Luhn or Damm for pure digit fields can still adopt ISO 7064 when a standards-cited scheme is required by a partner contract or when alphanumeric payloads must carry a single trailing check.
Integration use cases
Mint numeric IDs with MOD 11-2
Generate a sequential or random digit payload, call compute with system mod11-2, and store with_check so every new ID carries a standards-based trailing check character before print or email.
Validate typed or scanned codes at entry
When a user or scanner submits a full identifier, call validate with the matching system and block lookup when valid is false, showing expected_check_character to help correct a single mistype.
Technical questions
When should I use MOD 11-2 versus MOD 37-2?
Use mod11-2 for pure numeric payloads (check may be 0-9 or X). Use mod37-2 for uppercase alphanumeric payloads (check may be 0-9, A-Z, or *).
How do I compute a check character with this API?
POST with text set to the payload, system set to mod11-2 or mod37-2, and mode compute (or omit mode). The response includes check_character and with_check.
How do I validate an identifier that already has a check character?
POST with the full string, the matching system, and mode validate. The response includes valid, check_character, expected_check_character, and payload without the last character.