Background

Safety Data Sheets (SDS) are mandatory documents for every chemical product — solvents, adhesives, industrial gases, cleaning agents. Every manufacturer that supplies a hazardous chemical must provide one. In Japan, the governing standard is JIS Z 7253, which defines 16 sections covering chemical identity, hazard classification, first aid, storage, transport information, and more.

The Ministry of Health, Labour and Welfare (MHLW) published a standard JSON schema in March 2025 for electronic SDS data exchange between chemical management systems. The schema has roughly 200 deeply nested fields covering all 16 sections.

The problem is that real SDS documents don't arrive structured to this schema.

Why SDS documents are hard to parse

Even two documents both compliant with JIS Z 7253 will differ in ways that break rule-based parsers:

• Section order — manufacturers arrange the 16 sections freely within the standard
• Field labeling — the same data appears under different headings across JIS Z 7253, GHS/OSHA HazCom, GB/T 16483, CNS 15030, and company-specific layouts
• Value representation — "≥99.5%", "99.5% or higher", "approximately 100%" all mean the same thing
• Language mixing — Japanese SDS regularly embed English chemical names and CAS numbers mid-sentence
• Implicit information — section 9 (physical/chemical properties) often has half its fields missing because manufacturers only fill in what's relevant to their product

The MHLW schema compounds this: it has intentional typos that must be reproduced exactly. HumanExposureAndEmergencyMeasuress ends in double-s. TestGuidline is missing an e. Desclaimer has transposed letters. These are in the official spec, and validation fails if you "fix" them.

To handle SDS from international manufacturers (GHS/OSHA format) or Chinese suppliers (GB/T 16483 format) in the same pipeline, you'd need separate parsers for each format. Writing and maintaining those is impractical. I built sds-converter to handle this with an LLM instead.

The 16 sections

Installation and quick start

cargo install sds-converter

# PDF → MHLW standard JSON
export ANTHROPIC_API_KEY=sk-ant-...
sds-converter to-json --input input.pdf --output output.json

# MHLW JSON → JIS Z 7253-compliant Word document
sds-converter to-docx --input output.json --output result.docx --lang ja

# Schema validation
sds-converter validate --input output.json

# Extract raw text (no LLM call — useful for debugging)
sds-converter extract-text --input input.pdf

Supported input: PDF, DOCX, XLSX, TXT.

How the conversion works

Step 1: Text extraction

Text is pulled from the PDF or DOCX file. Use extract-text to inspect exactly what gets sent to the LLM — useful when extraction quality is lower than expected.

Note: Encrypted PDFs and scan-only (image) PDFs are not supported — text extraction requires selectable text.

Step 2: Parallel LLM extraction

The 16 sections are split into two groups and extracted with two parallel LLM calls, halving per-file latency:

• GROUP_A (sections 1–9): identification, hazard, composition, first aid, fire fighting, accidental release, handling, exposure, physical properties
• GROUP_B (sections 10–16): stability, toxicology, ecological, disposal, transport, regulatory, other

Results from both calls are merged. Sections skipped in the first pass are automatically retried. HTTP rate-limit responses (429/529) trigger exponential backoff retries (2s → 4s → 8s, up to 3 attempts).

Step 3: JSON output

The merged result is written as MHLW SDS data exchange format v1.0 JSON.

LLM backend and quality settings

Choosing a provider

# OpenAI GPT (gpt-4o-mini by default)
sds-converter to-json --input input.pdf --output output.json \
  --provider openai --api-key $OPENAI_API_KEY

# Google Gemini (gemini-2.0-flash by default)
sds-converter to-json --input input.pdf --output output.json \
  --provider gemini --api-key $GEMINI_API_KEY

# Local LLM via Ollama (any OpenAI-compatible endpoint)
sds-converter to-json --input input.pdf --output output.json \
  --provider local --base-url http://localhost:11434/v1 \
  --model llama3.2 --api-key dummy

Quality preset

--quality controls both the model and how much text is sent to the LLM per call:

At high, the full document text including the later sections (transport information, regulatory) is included. Use --quality high when complete 16-section coverage matters.

Batch mode

sds-converter to-json \
  --input-dir ./pdfs/ \
  --output-dir ./json/ \
  --lang ja \
  --concurrency 4

Validation

validate checks structural completeness of the extracted JSON and returns warnings without hard-failing — partial results are still usable.

sds-converter validate --input output.json

Examples of what it checks:

• Section 1: no product name (TradeNameJP or TradeNameEN)
• Section 1: SupplierInformation missing
• Section 2: neither Classification nor HazardLabelling extracted
• Section 3: CompositionAndConcentration list is empty

When using the library, convert_to_json returns a (SdsRoot, Vec<String>) tuple — the warnings are surfaced inline.

Output JSON structure

{
  "Datasheet": {
    "IssueDate": "2024-03-31",
    "SDS-SchemaVersionNo": "1.0"
  },
  "Identification": {
    "TradeProductIdentity": {
      "TradeNameJP": "Sample Product"
    },
    "SupplierInformation": {
      "CompanyName": "Sample Corp",
      "Phone": "03-0000-0000"
    }
  }
}

The full schema covers all 16 JIS Z 7253 sections with ~200 fields. The official spec and developer manual are on the MHLW website (Japanese).

Using as a library

[dependencies]
sds-converter-core = "0.1"

PDF → JSON

use sds_converter_core::{
    converter::{AnthropicBackend, LlmConfig},
    convert_to_json, ConvertConfig, Language,
};

#[tokio::main]
async fn main() -> anyhow::Result<()> {
    let backend = AnthropicBackend::new(
        std::env::var("ANTHROPIC_API_KEY")?,
        LlmConfig::default(),
    );
    let config = ConvertConfig {
        source_language: Some(Language::Japanese),
        output_language: Language::Japanese,
        ..Default::default()
    };
    let (sds, warnings) = convert_to_json(
        std::path::Path::new("input.pdf"), &backend, &config
    ).await?;
    for w in &warnings { eprintln!("WARN: {w}"); }
    std::fs::write("output.json", serde_json::to_string_pretty(&sds)?)?;
    Ok(())
}

JSON → Word document

use sds_converter_core::{convert_from_json, ConvertConfig, Language, SdsRoot};

fn main() -> anyhow::Result<()> {
    let sds: SdsRoot = serde_json::from_str(&std::fs::read_to_string("output.json")?)?;
    let config = ConvertConfig {
        output_language: Language::Japanese,
        ..Default::default()
    };
    convert_from_json(&sds, std::path::Path::new("result.docx"), &config)?;
    Ok(())
}

Custom LLM backend

use sds_converter_core::{LlmBackend, SdsError};

struct MyBackend;

impl LlmBackend for MyBackend {
    async fn complete(&self, system: &str, user: &str) -> Result<String, SdsError> {
        // Call your LLM API, return the raw JSON string response
        todo!()
    }
}

Language support

Comparison with alternatives

Open-source

Commercial (Japan)

sds-converter is the only open-source tool that supports the MHLW schema, runs entirely locally, and handles the full round-trip.

Crate structure

• sds-converter-core — library. LLM extraction, DOCX generation, MHLW schema types.
• sds-converter — CLI binary. to-json, to-docx, validate, extract-text subcommands.

Feedback welcome, especially on section 3 component table extraction and non-Japanese document accuracy.

https://github.com/kent-tokyo/sds-converter