GS1 DATA TOOL
FNC1 and group-separator tool
Diagnose variable-length AI boundaries without losing invisible separator characters during copy and paste.
Inputs
Results
Run the sample to see decoded fields and checks.
ON THIS DEVICE
Recent history
RULES USED
Method and formulas
ASCII code point 29 is represented visibly as <GS>. The tool can convert in either direction without altering other characters.
FNC1 is a symbology function; many scanners transmit it as ASCII 29 between variable-length fields, but scanner configuration varies.
GUIDE
What this tool does and when to use it
The FNC1 and group-separator tool processes scanner output containing ASCII code point 29, which GS1 standards use to delimit variable-length data fields after FNC1 characters in Code 128 or DataMatrix symbols. Scanners often emit this byte as an invisible control character between elements such as batch numbers or serial numbers. The converter replaces the raw byte with the visible token <GS> or reverses the mapping to restore the original byte for further processing or database storage. Use the tool when inspecting raw GS1 strings from handheld readers, validating label generation scripts, or debugging parsing routines that expect explicit separators. It operates entirely on the client side, accepting any printable ASCII input and preserving all non-control characters during conversion.
Technicians apply the visualizer after configuring scanners to transmit group separators rather than stripping them. This reveals field boundaries in concatenated strings that would otherwise appear as unbroken sequences of digits and letters. The bidirectional mapping supports both diagnostic review of live scanner feeds and preparation of test vectors that include the correct control byte. In high-volume logistics environments the tool helps confirm that variable-length fields terminate correctly before data reaches enterprise resource planning systems.
Worked example with realistic GS1 data
Consider the scanner string 01095060001343521727123110LOT-2048 followed by ASCII 29 then 21SN00042. The leading 01 indicates a GTIN-14, 17 marks the expiry date, 10 introduces the batch, and 21 holds the serial number. Insertion of the visible marker produces 01095060001343521727123110LOT-2048<GS>21SN00042. The following table breaks the string into its AI components after conversion.
| Position | AI | Data | Length | Terminator |
|---|---|---|---|---|
| 1-16 | 01 | 09506000134352 | 14 | fixed |
| 17-24 | 17 | 271231 | 6 | fixed |
| 25-36 | 10 | LOT-2048 | 8 | <GS> |
| 38-48 | 21 | SN00042 | 7 | end |
Reversing the operation removes every occurrence of the <GS> token and substitutes the single ASCII 29 byte, restoring a byte sequence identical to the original scanner transmission.
Second worked example with mixed fixed and variable fields
A second scanner transmission reads 00312345678901211725063010ABC123<GS>21XYZ789. Here the 00 AI denotes an SSCC-18, 17 the expiry, 10 the batch, and 21 the serial. After conversion the string becomes 00312345678901211725063010ABC123<GS>21XYZ789. The table below shows component boundaries.
| Position | AI | Data | Length | Terminator |
|---|---|---|---|---|
| 1-20 | 00 | 31234567890121 | 18 | fixed |
| 21-28 | 17 | 250630 | 6 | fixed |
| 29-38 | 10 | ABC123 | 6 | <GS> |
| 40-48 | 21 | XYZ789 | 6 | end |
Restoring the control byte yields the exact original scanner payload for direct comparison against expected GS1 syntax.
Formula and method table
| Input mode | Action | Output format | Preserved characters |
|---|---|---|---|
| ASCII 29 → <GS> | Replace byte 0x1D with literal five-character sequence | Human-readable string | All bytes except 0x1D |
| <GS> → ASCII 29 | Replace five-character token with single byte 0x1D | Binary-clean string | All bytes except the token |
Units and conversions notes
ASCII 29 corresponds to the group separator control character with hexadecimal representation 0x1D. No unit conversion occurs; the tool performs a strict one-to-one byte substitution while leaving every other code point unchanged. GS1 specifications define FNC1 as a symbology-level flag that many readers translate directly into this byte when variable-length fields appear. The visual token <GS> occupies five bytes in the displayed text but represents exactly one control byte in the underlying data stream. Users must ensure downstream parsers treat the restored byte as a delimiter rather than printable data. The fuller reference table below summarizes related control characters and their common scanner mappings.
| Control name | Decimal | Hex | GS1 usage | Typical scanner emission |
|---|---|---|---|---|
| Group separator | 29 | 0x1D | Variable field delimiter | <GS> token or raw byte |
| Record separator | 30 | 0x1E | Rare in GS1 | Usually suppressed |
| Unit separator | 31 | 0x1F | Not used in GS1 | Never emitted |
| FNC1 | N/A | symbology flag | Start or delimiter flag | Translated to 0x1D |
Limitations
The tool does not interpret or validate GS1 application identifiers, nor does it enforce length rules for any AI. Scanner firmware may omit the separator entirely when the final field is fixed-length, producing output that appears correct yet lacks delimiters. Some readers transmit FNC1 as a different control byte or suppress it based on configuration; the converter cannot detect or correct such variations. Multi-byte UTF-8 sequences containing 0x1D are not supported because the input domain is restricted to single-byte ASCII. The tool also cannot handle concatenated symbols that use explicit FNC1 characters inside the data stream rather than the group separator byte. Finally, it provides no checksum verification for any encoded identifier.
Common mistakes
- Assuming every GS1 string contains an explicit separator after every AI, whereas fixed-length fields such as GTIN-14 never require one.
- Copying the visible <GS> token into barcode generation software that expects the raw control byte, resulting in literal text instead of a delimiter.
- Confusing the FNC1 character used at the start of a symbol with the group separator used between fields; only the latter maps to ASCII 29.
- Overwriting original scanner logs with converted text before confirming that the downstream system accepts the restored byte sequence.
- Expecting the tool to expand or validate application identifier lengths when only byte substitution is performed.
- Feeding UTF-8 encoded strings that embed 0x1D inside multi-byte sequences, which the ASCII-only converter silently corrupts.
- Using the converter on data already containing the literal five-character string <GS> without first escaping or removing those characters.
COMMON QUESTIONS
Frequently asked questions
How does the tool distinguish a genuine ASCII 29 from other control bytes that some scanners emit?
It performs an exact match on byte value 0x1D only. Any other control character remains untouched and is displayed as its literal glyph or escaped form depending on the browser rendering.
What occurs when the input contains multiple consecutive group separators?
Each 0x1D byte is independently replaced by <GS> or restored, preserving the exact count and position of separators without collapsing or inserting additional delimiters.
Does the converter modify any application identifier data such as lot numbers containing the substring GS?
No. Only the five-character token <GS> or the raw byte 0x1D is processed; all other character sequences including the letters G and S remain unchanged.
Can the tool be used to prepare test data for systems that reject control bytes in JSON payloads?
Yes. Convert the scanner string to the visible <GS> form first, then embed the resulting text in JSON; the reverse conversion restores the original byte before transmission to the scanner parser.
What scanner configuration setting most commonly prevents the group separator from appearing?
Enabling the "transmit FNC1 as nothing" or "strip variable-length terminators" option removes the byte entirely, leaving concatenated fields without any delimiter for the tool to visualize.
How many group separators can a single GS1 element string legally contain?
GS1 rules permit one separator after each variable-length field except the final field, so the maximum equals the number of variable-length AIs minus one when the string ends with a fixed-length element.
Is the output byte sequence guaranteed to be identical to the original scanner transmission after round-trip conversion?
Yes, provided no additional whitespace or line endings were introduced during copy-paste; the tool performs lossless substitution of the single control byte.
What happens if a serial number field itself contains the literal five characters <GS>?
The reverse conversion will treat those characters as a delimiter and split the field incorrectly; users must escape or encode such data at the label-printing stage to avoid ambiguity.