This guide is intended for regulatory teams at chemical manufacturers, particularly small and mid-size US companies that operate in multiple markets or plan to do so. It outlines SDS language requirements in the US, Canada, the EU, Great Britain, and Mexico, and provides a checklist for evaluating software during a demo.
This article is for informational purposes only and does not constitute legal advice. Please consult the primary sources linked below and confirm details with your regulatory professional.
SDS language requirements by region
GHS gives countries common hazard criteria and a 16-heading SDS format, and each country adopts them through its own law. GHS does not set one language for everyone. Its guidance on preparing SDSs notes that its use “is dependent on importing countries requirements for SDS” (GHS Rev. 11, Annex 4, A4.1.2). Each jurisdiction sets its own language rule.
| Region | What the primary source says about SDS language | Where to read it |
|---|---|---|
| United States (OSHA HCS) | The manufacturer or importer “shall ensure that the safety data sheet is in English (although the employer may maintain copies in other languages as well)”. | 29 CFR 1910.1200(g)(2) |
| Canada (WHMIS) | For hazardous products intended for use in a workplace in Canada, the information elements on an SDS and on a label “must be in both official languages of Canada”. One bilingual SDS, or two unilingual parts that together make one bilingual SDS, are both allowed. | Hazardous Products Regulations, s. 6.2 |
| European Union (REACH) | The SDS “shall be supplied in an official language of the Member State(s) where the substance or mixture is placed on the market, unless the Member State(s) concerned provide otherwise”. Some Member States require more than one language or accept another, so check the national rule. | REACH Regulation, Article 31(5), consolidated text |
| Great Britain (UK REACH) | The SDS “shall be supplied in English and may also be supplied in any other language”. | UK REACH, Article 31(5) |
| Mexico | Under the workplace norm, the SDS (hoja de datos de seguridad, HDS) must be “elaborarse o tenerse en idioma español”: prepared or held in Spanish. | NOM-018-STPS-2015, 9.1 b) and Appendix E.1 a) |
This table addresses SDS language requirements only. Label language rules differ. Note that Northern Ireland follows EU REACH and CLP, so refer to HSENI guidance for specific language expectations.
The following four practical points summarize the table above.
A single product may require multiple SDS documents. For example, a product sold in the US, Canada, and Mexico needs SDS content in English (US and Canada), French (Canada), and Spanish (Mexico), each complying with the respective country's requirements. For the EU, include the official language(s) of each Member State where the product is marketed.
The EU consists of multiple official languages, and requirements vary by Member State. Some require more than one language or have specific provisions, so always verify national requirements rather than assuming English is sufficient.
Translation and localization are distinct. For example, in EU Section 1, REACH Annex II requires the emergency telephone number of an official advisory body in the relevant Member State, if available. Simply translating a US Section 1 may not meet this requirement.
All language versions of an SDS must be updated. REACH Article 31(9) requires prompt updates when new hazard or risk-management information arises, and mandates distribution of the revised version to all recipients from the past 12 months. In the US, 29 CFR 1910.1200(g)(5) requires updates within three months of learning significant new information. Maintaining multiple language versions means each must be updated accordingly.
What regulatory teams need from SDS authoring software with multilingual support
A controlled standard-phrase library
Hazard and precautionary statements are the core of Section 2 and of the label, and their wording is standardized. GHS gives each one a code (for example H315 or P305 + P351 + P338). The codes are for reference. In the GHS wording, they “are not part of the hazard statement text and should not be used to replace it” (GHS Rev. 11, Annex 3, A3.1.1.3 for hazard statements and A3.2.2.2 for precautionary statements). The text itself has to appear in the reader’s language.
The GHS text also shows how translation is meant to work. Precautionary statements are broken into single sentences or parts of sentences “to facilitate translation into the languages of users”. Combined statements are assembled from the single ones, and “translation of only the single precautionary statements is required” (GHS Rev. 11, Annex 3, A3.2.5.2.1). GHS is guidance until a country adopts it, but the approach is a useful model. So a good phrase library:
keys every phrase to its GHS code, so each statement is translated once and reused;
assembles combined statements from the translated single statements;
supports controlled wording variants for precautionary statements, within any limits set by the competent authority. GHS allows minor textual variations “subject to any requirements of competent authorities”, and says any variation should be applied consistently on the label and the SDS (GHS Rev. 11, Annex 3, A3.2.5.3.1 and A3.2.5.3.2);
keeps the label and the SDS in step. Mexico’s NOM-018 requires the SDS to match the information used on the signage (9.1 f) and 10.2).
Per-section handling, not one-pass translation
An SDS is not one kind of text. Sort each section’s content into three types and ask how the software treats each:
Standard phrases. Hazard statements, precautionary statements, section headings. These come from the library.
Structured data. Names, CAS numbers, UN numbers, concentrations, physical properties, exposure limits. These are not translated, but their format and units still change by region.
Free text. Handling notes, first-aid detail, company-specific wording. These need translation, and a review.
A tool that runs the whole SDS through a translation engine as one block skips this distinction. Ask to see the same section in two languages, and ask which type each line came from.
Consistency across language versions
The strongest way to keep languages consistent is to not maintain them separately. Classification, composition and properties live in one product record. Each language version is generated from that record. When the record changes, every language version is flagged. When language versions are separate documents that people edit by hand, they drift.
A review workflow for every language version
None of the sources quoted above (HCS, HPR, REACH and CLP, their GB versions, NOM-018) requires a native-speaker reviewer or sets translator qualifications. Under REACH Annex II 0.2.3 (EU and GB) the SDS must be prepared by a competent person who has had appropriate training, and GHS says the same (Annex 4, A4.2.2.1). The rules do not spell out whether that competence includes language skill. Native-speaker review is good practice, and the supplier remains responsible for the content of every language version.
Look for a workflow that:
flags low-confidence or changed items instead of asking reviewers to reread everything;
blocks publication until a person approves;
records who approved and when.
Version control across languages
In every regime covered here an SDS carries a date. In the EU, an updated SDS is identified as “Revision: (date)” (Article 31(9)). In practice you need one revision history across all language versions, a way to see which version each customer received, and a clear rule for when a change in one region triggers a revision in another.
Regional formats
The 16 headings are shared. The formatting and content rules are not. Three examples from the primary sources:
Mexico’s NOM-018 asks for each SDS page to be numbered with the total page count (for example “Página 1/3”) and to show the substance or mixture name on every page (Appendix E, E.1 h) and i)). REACH Annex II allows either a page total or a “continued” marker, so this is stricter, not new. The Section 16 statement is required text (9.2 p)).
Canada requires the item number to be placed immediately before each heading (HPR s. 4(1)(a)).
The US requires all 16 headings but does not enforce the content of Sections 12 to 15 (29 CFR 1910.1200(g)(2), Note 2; Appendix D). Canada allows the content of items 12 to 15 to be omitted (HPR s. 4(2)). The EU and Great Britain list all 16 headings in Article 31(6), and Annex II sets the content for each.
A multilingual tool that only swaps the language inside one template will not produce these differences. The template itself has to change with the region.
Where multilingual SDS programs go wrong
Common failure modes in multilingual SDS programs, and the fix for each.
Translating hazard phrases ad hoc. Different authors render the same statement differently. Fix: one controlled library, one approved translation per phrase.
Assembling combined precautionary statements by hand. Errors creep into P-statement combinations. Fix: build them from the translated single statements, as GHS describes.
Translating a finished English SDS instead of authoring from the record. Any late change to the English text is missed in the other languages. Fix: generate all languages from the same product record.
Letting one language lag. The English SDS is revised. The French and Spanish versions wait. Fix: flag every affected version at the moment of change, and track their status together.
Reusing one regional layout for every market. A US-shaped SDS handed to an EU customer, or the reverse. Fix: regional variants with their own required content and layout.
Leaving local details unadapted. Emergency numbers, supplier contacts and units that only make sense in one country. Fix: treat Section 1 and units as regional data.
No record of who approved a translation. Fix: a record of approval for each language version.
Full-document machine translation with no review. It bypasses the phrase library and the reviewer. Fix: library for standard text, a qualified person for the rest.
Evaluation checklist: SDS authoring software with multilingual support
Use this in a demo. Bring your own supplier SDSs and a list of the markets you sell into.
| # | Ask | What good looks like | How to test it |
|---|---|---|---|
| 1 | Where do standard phrases come from? | A controlled library keyed to GHS codes, with one approved translation per phrase per language | Ask to see H315 and P305 + P351 + P338 in three languages |
| 2 | How are combined precautionary statements built? | From the translated single statements | Ask how a combined statement is assembled |
| 3 | Which languages, and which regions? | A clear statement of which languages and which regions are supported. Regions and languages listed separately | Ask for your top three markets from one record |
| 4 | How is free text handled? | A defined step with review, not silent machine translation | Pick a free-text field and follow it through to the output |
| 5 | Do all languages come from one record? | Yes. No separate document per language | Change a composition value and see which versions are flagged |
| 6 | Who approves the SDS before it publishes? | Flagged items for review, approval by a person, a record of who approved and when | Ask to see the approval screen and the audit trail |
| 7 | Can anything publish without approval? | No | Try to publish an unreviewed draft |
| 8 | How are regional formats handled? | Region-specific templates and required content, not one template with swapped text | Compare a US, EU and Mexico output for the same product |
| 9 | How are updates propagated? | A regulatory change flags affected products and every language version | Ask what happens when a listed substance is reclassified |
| 10 | What happens to your data? | Formulations stay private and are not used to train AI models. Export is available in a structured form | Ask for the data terms in writing |
How Valenc approaches multilingual SDS authoring
Valenc is software. It does not offer SDS authoring as a service; it works with third-party partners who do authoring. Valenc classifies first, then writes the SDS from the classified product record. That order matters for languages. Regional variants and language variants come from the same record, so no new record is needed for each variant. A change to the formulation updates the record once, and all affected variants are flagged for review.
Phrases in 25+ languages, including hazard and precautionary statements, come from a curated library. Because standard phrases come from a curated library, translations stay consistent across SDSs and language versions. Valenc drafts all 16 sections and can draft SDSs for multiple regions. Regions supported today are the US, Canada, Mexico, the EU, the UK and the UN GHS module. More regions are being added.
A review agent flags items that need a person’s decision. Nothing is published until a person approves it. There is a full audit trail from the source PDF to the published SDS.
Valenc’s classification is a deterministic rules engine, not a language model. The same inputs give the same result, and the rule behind each classification is shown. That helps keep every language version telling the same hazard story. See how Valenc classifies and why classification cannot be a guess.
Regulatory monitoring agents watch OSHA, EPA, REACH and CLP lists and flag affected SDSs in your library. Your compositions and formulations stay private and are never used to train AI models. If you move a library in, you can go live within weeks. Data is portable: export anytime with no fees, and a REST API connects to ERP or PLM systems. For the authoring workflow itself, see SDS authoring for multiple regions.
When evaluating solutions, use our scorecard for comparing SDS authoring software to align your choice with your priorities. For teams weighing a software investment against outsourcing, our comparison of SDS authoring services and software covers scalability, regulatory control, and long-term risk.
Frequently asked questions
What language does an SDS have to be in?
Language requirements are determined by your product’s target market. For hazardous workplace chemicals: the US mandates English (HCS); Canada, both English and French (HPR s. 6.2); Great Britain, English; Mexico, Spanish (NOM-018). The EU requires an official language for each Member State where the product is marketed, and some require additional languages. Northern Ireland follows EU rules. Note: Label language requirements may differ from SDS rules—see the table above for authoritative sources.
Does an SDS in the US need to be in Spanish?
OSHA’s Hazard Communication Standard requires the SDS to be in English. The employer may keep copies in other languages as well. Check with your regulatory professional if you have obligations beyond the HCS.
What does Canada’s bilingual SDS rule allow?
The regulation quoted above allows either one bilingual SDS or two unilingual parts that together make one bilingual SDS. Confirm how this applies to your products with your regulatory professional.
Is machine translation acceptable for SDSs?
While regulations specify required languages, they do not dictate production methods. Best practice is to use a controlled phrase library for standardized content and ensure all free text is reviewed by qualified personnel. Relying solely on generic machine translation introduces compliance and reputational risk.
How many languages do I need?
Begin with a strategic assessment of your current and planned markets. Map each product’s destination to local language requirements, and confirm the software supports those regions and languages.
What is the best multilingual SDS authoring software?
The optimal platform is the one that best supports your company’s compliance objectives and global operations, according to your weighted evaluation criteria. Seek solutions that unify all language versions under a single product record, ensure consistency through a controlled phrase library, adapt to region-specific requirements, and offer governance features, including approval workflows and audit trails. For a detailed evaluation rubric, refer to our scorecard for comparing SDS authoring software.
See it on your own supplier SDSs
Valenc provides a customized demonstration leveraging your own supplier SDSs—highlighting end-to-end data extraction, rules-based classification, and draft generation based on your real-world chemistry portfolio. Specify your target markets to ensure the demo addresses your organization’s regulatory and operational needs. Request a demo.
Focusing on US regulatory compliance? Access our in-depth OSHA HazCom standard guide and the HCS 2024 checklist. For help choosing a system, see our SDS management software guide.