Build a Code 128 barcode payload and checksum
Check that a label value fits Code 128 Set B and get the symbol values a printer needs: KIT-128 starts with value 104 and its checksum value is 77. Any unsupported character is flagged by its position. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Worked example
- Text
- KIT-128
- Payload
- KIT-128
- Code set
- B
- Start symbol value
- 104
- Checksum symbol value
- 77
Unsupported characters produce a precise input error instead of a barcode that may fail later.
Know exactly which characters are accepted
Code 128 is a family of compact symbol encodings rather than a direct picture of arbitrary Unicode text. This builder deliberately uses Code Set B, the most practical set for ordinary identifiers containing letters, digits, punctuation, and spaces. It accepts printable ASCII characters from U+0020, the space, through U+007E, the tilde.
That range includes uppercase and lowercase English letters, decimal digits, and familiar punctuation. It rejects tabs, line breaks, control codes, accented letters, emoji, and every other character outside that range. The restriction is explicit because silently replacing or stripping a character would change an identifier and could attach a label to the wrong record.
When validation fails, the error reports the zero-based character index and Unicode code point, so an application can identify the exact source value that needs correction. If a workflow requires control characters, FNC symbols, Code Set A, or numeric compaction with Code Set C, it should use an encoder designed for that richer symbol-selection contract rather than pretending those values belong to Set B.
How the symbol values and checksum are calculated
For Code Set B, each accepted character maps to a data symbol by subtracting 32 from its ASCII code. A space therefore becomes symbol zero, the digit zero becomes symbol 16, uppercase A becomes symbol 33, and tilde becomes symbol 94. To calculate the checksum, the builder begins with that start value, then adds each data symbol multiplied by its one-based position.
The first data symbol has weight one, the second has weight two, and so on. Returning the intermediate data values is useful for audits because another implementation can reproduce every term of the checksum instead of trusting an opaque final number. The algorithm uses integer arithmetic only and always returns the same result for the same input.
What you can do with it
Prepare label-printer commands
Validate a warehouse identifier and obtain the exact Code Set B values needed before assembling a printer-specific barcode command.
Diagnose rejected identifiers
Locate a control character, accented letter, or other unsupported code point before it reaches a production labeling workflow.
FAQ
Which characters are supported?
Printable ASCII from space (U+0020) through tilde (U+007E), which is the character repertoire used here for Code 128 Code Set B.
Does this generate a barcode image?
Rendering bars, quiet zones, dimensions, and image formats belongs to a barcode renderer.
How is the Code 128 checksum calculated?
Start from 104, the start value of Code Set B, then add each data symbol multiplied by its position, counting from one. Divide the total by 103 and keep the remainder: for KIT-128 that remainder, the checksum value, is 77.
Should I add the checksum to the end of my text?
No. The checksum is a symbol value that the barcode renderer places after the data and before the stop pattern. It is not a digit to type onto the original text, which stays exactly as you entered it.
What happens if my text contains an accent or a line break?
It is rejected with a precise message that gives the character's position, counted from zero, and its Unicode code point. Nothing is stripped or replaced, because changing an identifier could put a label on the wrong record.
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/barcode-code128-payload \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"text":"KIT-128"}'const res = await fetch("https://api.kit.forhosting.com/enc/barcode-code128-payload", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"text": "KIT-128"
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/enc/barcode-code128-payload",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"text": "KIT-128"
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/enc/barcode-code128-payload", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"text":"KIT-128"}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"text":"KIT-128"}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/enc/barcode-code128-payload", 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": "KIT-128"
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "enc.barcode_code128_payload",
"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.
Limits
max_chars | 4096 |
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 Code 128 payload builder validates a text value before it reaches a barcode renderer, converts every supported character into its Code Set B symbol value, and calculates the required modulo-103 checksum.
Know exactly which text this payload accepts
Empty text also fails, and the declared maximum length keeps browser and API execution bounded.
How the symbol values and checksum are calculated
The returned data_symbol_values array preserves this order and excludes both the start and checksum symbols, which makes the boundary between user data and structural symbols unambiguous. The start_symbol_value is 104, the standard start value for Code Set B. The final sum modulo 103 is returned as checksum_symbol_value. This is the symbol value that a renderer places after the data and before the stop pattern; it is not a decimal character to append to the original text.
Use the result safely in barcode and label systems
The result is aimed at software that already knows how to turn Code 128 symbol values into bars, printer commands, or a test assertion. In automated pipelines, validate and calculate before sending commands to a label printer, then retain the response beside the generated artifact for traceability. Because no network, storage, randomness, or current time is involved, results remain stable across environments. A renderer can emit the start symbol, then each value in data_symbol_values, then checksum_symbol_value, and finally the mandatory stop pattern. The payload field is returned unchanged so logs and downstream records can associate the calculated symbols with the exact source text. This capability does not draw an SVG or PNG, choose dimensions, add quiet zones, or verify that a physical print can be scanned; those are rendering and print-quality concerns. It also does not include the stop pattern in the numeric array because the stop pattern is structural and does not participate in the checksum. In tests, compare both the ordered data values and checksum rather than checking only the payload. Browser execution is useful for an immediate manual check, while API execution costs $0.002 per request when the calculation belongs in a repeatable integration.
Integration use cases
Create barcode regression fixtures
Generate auditable symbol arrays and checksums for tests that compare an independent Code 128 renderer against known deterministic values.
Technical questions
Should I append the checksum number to my text?
No. The checksum is a Code 128 symbol value for the renderer, not text to append to the original payload.
What happens when the text contains an emoji or line break?
The request fails with invalid_input and identifies the first unsupported character by its zero-based index and Unicode code point.
What does API execution cost?
Each API request costs $0.002. The same deterministic calculation can also run free in the browser.