Convert TOML to JSON

Drag and drop files here or click to select.
Max file size 100mb.
Uploading progress:

TOML vs JSON Format Comparison

Aspect TOML (Source Format) JSON (Target Format)
Format Overview
TOML
Tom's Obvious Minimal Language

A minimal configuration file format created by Tom Preston-Werner with clear, unambiguous semantics. Designed to be easy to read due to obvious mapping to hash tables. Supports strings, integers, floats, booleans, dates, arrays, and tables. Formally specified with a comprehensive test suite.

Configuration Format Formally Specified
JSON
JavaScript Object Notation

A lightweight data interchange format that is easy for humans to read and write and easy for machines to parse and generate. Based on a subset of JavaScript, JSON is the dominant format for web APIs, configuration, and data exchange. Specified by RFC 8259 and ECMA-404, it is supported natively by virtually every programming language.

Data Interchange RFC Standard
Technical Specifications
Structure: Key-value pairs with tables and arrays
Encoding: UTF-8 required
Format: Plain text, human-readable
Compression: None
Extensions: .toml
MIME Type: application/toml
Structure: Objects, arrays, and primitive values
Encoding: UTF-8 (default), UTF-16, UTF-32
Format: Text-based data interchange
Compression: None (gzip common over HTTP)
Extensions: .json
MIME Type: application/json
Syntax Examples

TOML configuration format:

[package]
name = "myapp"
version = "1.0.0"
authors = ["Dev <[email protected]>"]

[dependencies]
serde = { version = "1.0", features = ["derive"] }
tokio = "1.28"

Equivalent JSON representation:

{
  "package": {
    "name": "myapp",
    "version": "1.0.0",
    "authors": ["Dev <[email protected]>"]
  },
  "dependencies": {
    "serde": {
      "version": "1.0",
      "features": ["derive"]
    },
    "tokio": "1.28"
  }
}
Content Support
  • String values (basic and literal)
  • Integer and float numbers
  • Boolean values
  • Date and time types (RFC 3339)
  • Arrays (typed and mixed)
  • Tables and inline tables
  • Array of tables
  • Comments
  • Strings (double-quoted, Unicode)
  • Numbers (integer and float)
  • Booleans (true/false)
  • Null values
  • Arrays (ordered, mixed types)
  • Objects (key-value pairs)
  • Nested structures (unlimited depth)
  • No comments (by specification)
Advantages
  • More readable for configuration
  • Comments allowed
  • Native date/time types
  • No trailing commas issues
  • Multiline strings
  • Less verbose for flat configs
  • Universal language support
  • Native JavaScript integration
  • Dominant API interchange format
  • JSON Schema for validation
  • Null value support
  • Extensive tooling ecosystem
  • Browser-native parsing
Disadvantages
  • Smaller ecosystem than JSON
  • Not suitable for data interchange
  • No null value type
  • Fewer validation tools
  • Not supported by web APIs
  • No comments allowed
  • No date/time types
  • Verbose for configuration files
  • Trailing comma errors
  • No multiline strings
  • Number precision limitations
Common Uses
  • Rust project configuration (Cargo.toml)
  • Python project metadata (pyproject.toml)
  • Hugo static site configuration
  • Netlify deployment settings
  • Application settings files
  • REST API request/response data
  • Web application configuration
  • package.json (Node.js)
  • NoSQL database storage (MongoDB)
  • Configuration (tsconfig.json, etc.)
  • Data serialization and exchange
Best For
  • Human-edited configuration files
  • Project metadata with comments
  • Settings requiring date types
  • Readable config documentation
  • API data interchange
  • JavaScript/web applications
  • Machine-to-machine communication
  • Cross-language data sharing
Version History
Introduced: 2013 (Tom Preston-Werner)
Current Version: TOML v1.0.0 (2021)
Status: Stable, formally specified
Evolution: Community-driven development
Introduced: 2001 (Douglas Crockford)
Standards: RFC 8259 (2017), ECMA-404 (2013)
Status: Active, universal standard
Evolution: Minimal changes, highly stable
Software Support
Editors: VS Code, Vim, Sublime Text, IntelliJ
Languages: Rust, Python, Go, JavaScript, Java
Tools: Cargo, pip, Hugo, Netlify CLI
Validation: taplo, toml-lint
Languages: All (native in JavaScript, Python, etc.)
Browsers: JSON.parse() in all browsers
APIs: REST, GraphQL, WebSocket
Tools: jq, JSON Schema, JSONPath, Postman

Why Convert TOML to JSON?

Converting TOML to JSON is one of the most common and practical configuration format conversions. JSON is the universal data interchange format of the web, supported natively by JavaScript and virtually every programming language. When your TOML configuration data needs to be consumed by web APIs, JavaScript applications, or tools that expect JSON input, this conversion provides a seamless bridge between the two formats.

TOML and JSON share fundamental similarities in their data models: both support objects/tables, arrays, strings, numbers, and booleans. TOML tables map directly to JSON objects, TOML arrays to JSON arrays, and primitive values convert one-to-one. The key difference is that TOML dates become JSON strings (since JSON has no date type) and TOML comments are stripped (since JSON does not support comments).

This conversion is especially valuable in polyglot development environments where Rust or Python projects use TOML for configuration but need to share settings with Node.js services, web frontends, or REST APIs that consume JSON. Rather than maintaining duplicate configuration files, teams can use TOML as the source of truth and generate JSON for consumption by other systems.

JSON's massive ecosystem of validation tools (JSON Schema), query languages (JSONPath, jq), and processing libraries makes it an ideal target format for configuration data that needs to be validated, queried, or transformed programmatically. Converting TOML to JSON unlocks access to this entire ecosystem while preserving the human-friendly TOML format for direct editing.

Key Benefits of Converting TOML to JSON:

  • Universal Compatibility: JSON is supported by every programming language
  • Web API Integration: Use TOML config data in REST/GraphQL APIs
  • JavaScript Native: JSON.parse() in every browser and Node.js
  • Validation: Apply JSON Schema validation to your config data
  • Tooling Ecosystem: Access jq, JSONPath, and thousands of JSON tools
  • Database Storage: Store in MongoDB, PostgreSQL JSONB, and more
  • Lossless Mapping: TOML data model maps cleanly to JSON

Practical Examples

Example 1: Rust Project Config to JSON

Input TOML file (Cargo.toml):

[package]
name = "myapp"
version = "1.0.0"
edition = "2021"
authors = ["Dev <[email protected]>"]

[dependencies]
serde = { version = "1.0", features = ["derive"] }
tokio = { version = "1.28", features = ["full"] }
axum = "0.6"

Output JSON file (Cargo.json):

{
  "package": {
    "name": "myapp",
    "version": "1.0.0",
    "edition": "2021",
    "authors": ["Dev <[email protected]>"]
  },
  "dependencies": {
    "serde": {
      "version": "1.0",
      "features": ["derive"]
    },
    "tokio": {
      "version": "1.28",
      "features": ["full"]
    },
    "axum": "0.6"
  }
}

Example 2: Application Settings for API

Input TOML file (config.toml):

[server]
host = "0.0.0.0"
port = 3000
cors_origins = ["https://app.example.com", "https://admin.example.com"]

[auth]
jwt_secret = "change-me-in-production"
token_expiry = 3600
refresh_enabled = true

[features]
dark_mode = true
beta_features = ["new-dashboard", "ai-search"]

Output JSON file (config.json):

{
  "server": {
    "host": "0.0.0.0",
    "port": 3000,
    "cors_origins": [
      "https://app.example.com",
      "https://admin.example.com"
    ]
  },
  "auth": {
    "jwt_secret": "change-me-in-production",
    "token_expiry": 3600,
    "refresh_enabled": true
  },
  "features": {
    "dark_mode": true,
    "beta_features": ["new-dashboard", "ai-search"]
  }
}

Example 3: pyproject.toml to JSON for CI/CD

Input TOML file (pyproject.toml):

[project]
name = "analytics-lib"
version = "2.0.0"
requires-python = ">=3.10"

[project.dependencies]
numpy = ">=1.24"
pandas = ">=2.0"

[tool.ruff]
line-length = 100
target-version = "py310"

[tool.ruff.lint]
select = ["E", "F", "I"]

Output JSON for CI/CD pipeline:

{
  "project": {
    "name": "analytics-lib",
    "version": "2.0.0",
    "requires-python": ">=3.10",
    "dependencies": {
      "numpy": ">=1.24",
      "pandas": ">=2.0"
    }
  },
  "tool": {
    "ruff": {
      "line-length": 100,
      "target-version": "py310",
      "lint": {
        "select": ["E", "F", "I"]
      }
    }
  }
}

Frequently Asked Questions (FAQ)

Q: Is the conversion from TOML to JSON lossless?

A: Nearly lossless. TOML's core data types (strings, integers, floats, booleans, arrays, tables) map directly to JSON equivalents. Two things are lost: TOML comments (JSON does not support comments) and TOML date/time values (which become JSON strings since JSON has no date type). The structural data is fully preserved.

Q: How are TOML dates handled in JSON?

A: TOML supports native date, time, and datetime types (RFC 3339 format). Since JSON has no date type, these values are converted to ISO 8601 formatted strings. For example, TOML's created = 2024-01-15T10:30:00Z becomes JSON's "created": "2024-01-15T10:30:00Z". Applications consuming the JSON can parse these strings back into date objects.

Q: Why would I use TOML instead of writing JSON directly?

A: TOML is much more pleasant for humans to read and edit: it supports comments, has cleaner syntax without excessive braces and commas, allows multiline strings, and provides native date types. Many teams use TOML as the human-editable source and convert to JSON for machine consumption. This gives you the best of both worlds.

Q: Can I use the JSON output with JSON Schema validation?

A: Yes. Once converted to JSON, you can validate the data against a JSON Schema to ensure configuration values meet your requirements. This is a powerful pattern: maintain human-friendly TOML files, convert to JSON, then validate with JSON Schema in your CI/CD pipeline to catch configuration errors early.

Q: How do TOML inline tables convert to JSON?

A: TOML inline tables (e.g., serde = { version = "1.0", features = ["derive"] }) convert to regular JSON objects. There is no distinction between inline and regular tables in the output since JSON has only one object type. The result is a clean nested JSON object with the same key-value structure.

Q: What about TOML integer types and JSON numbers?

A: TOML distinguishes between integers and floats, and both map to JSON numbers. However, JSON has a precision limit for large numbers (safe integer range is up to 2^53). Very large TOML integers may need to be converted to strings in JSON to prevent precision loss. Standard configuration values are well within safe range.

Q: Can I process the JSON output with jq or similar tools?

A: Absolutely. Once in JSON format, you can use jq for filtering and transformation, JSONPath for querying, and any JSON processing library. For example, jq '.dependencies | keys' would extract all dependency names. This is one of the primary reasons for converting TOML to JSON.

Q: How does this differ from TOML to YAML conversion?

A: Both JSON and YAML can represent the same data structure from TOML. JSON is more widely supported in web APIs and JavaScript ecosystems, while YAML is more human-readable and supports comments. Choose JSON for machine consumption and API integration; choose YAML if the output needs to be human-editable and you need comments.