Inside The /ghs Label Builder

I built /ghs because small labs and field teams still end up making chemical labels in spreadsheets, fragile templates, or desktop software that only one person knows how to use. I wanted a shorter path from reviewed chemical information to readable output.

The TKOResearch label builder is a small tool for that task. This January 2026 note has been updated after a September source review to describe the canvas workflow. That review checked the implementation, not a live printer, a production AI request, or regulatory compliance of a generated label.

One layout for preview and output

The current design uses a canvas renderer for the on-screen preview, PNG export, and printed image. The purpose is consistency: a separate print template can easily drift from the preview when spacing, pictograms, or long hazard statements change.

The workflow supports chemical labels and hazard-area signs. A user supplies the product details, chooses pictograms and a signal word, enters hazard and precautionary text, and reviews the layout at the intended size. Optional QR content can provide an identifier, but it should not displace information that needs to be readable on the physical label.

The implementation includes JSON export and import for saving builder state. I would use that explicit save path when a draft matters. Browser editing state and a downloaded file have different lifetimes; neither should be confused with an organization-wide inventory or approved labeling record.

Layout cannot determine the hazard

A clean label can still contain the wrong classification. Product identity, concentration, formulation, and the current safety data sheet matter. A sample chemical is a starting point for layout, not an authoritative classification for every container with a similar name.

In the United States, OSHA's Hazard Communication Standard distinguishes requirements for shipped containers and workplace labeling. Its allocation of label elements connects classifications to signal words, statements, and pictograms. The tool does not decide which regulatory situation applies to a particular user.

Before printing, compare the draft with the current SDS and the organization's labeling procedure. After printing, check the physical result: text size, contrast, clipped statements, pictogram visibility, and whether the label remains legible on the actual container. A preview that fits on a monitor is not a print acceptance test.

Optional AI changes the data path

Manual layout and rendering happen in the browser. An optional AI request sends selected chemical information to a server endpoint and then to its configured model provider. That means AI-assisted drafting has a different privacy boundary from local editing.

The assistance can propose label fields or wording, but model output remains a draft. It may omit a hazard, combine information from the wrong formulation, or shorten a statement in a way that changes its meaning. The useful review is against the product's authoritative materials, not whether the result sounds technical.

For routine label work, I prefer entering verified information directly. AI assistance should reduce transcription effort only where its output can be checked, and its availability should not become a dependency for printing an already reviewed label.

What I want the tool to improve

The useful improvements are practical: clearer SDS references, better handling of long statements, predictable output sizes, and organization-specific presets with an explicit review state. Those are design priorities rather than claims that the current tool provides an approval system.

A useful bug report identifies the label size, browser, input that clipped or moved, and expected output. With that information, a rendering problem becomes reproducible. The aim is a reliable small utility whose limits are understandable to the person placing the label on a real container.