Convert YAML to TOML Online
Convert YAML configuration to TOML, free, in your browser.
title = "My Project" version = "1.0.0" [server] host = "localhost" port = 8080 [database] host = "db.example.com" name = "myapp"
Use cases
From Docker and GitHub Actions to Rust and Hugo
Jekyll→Hugo migration
Convert Jekyll's YAML front matter to TOML to migrate content to Hugo.
Modern Python
Extract configuration from YAML to adapt it to pyproject.toml following PEP 621.
100% private
Your YAML never leaves your browser. No servers, no sign-up.
Real-time
Live conversion with instant YAML syntax error detection.
How it works
Three steps, no hassle
Paste your YAML
Paste YAML into the editor. Supports docker-compose.yml, GitHub Actions workflows, Ansible playbooks, and any valid YAML 1.2.
Conversion to TOML
The converter transforms YAML maps and lists into TOML sections and arrays. Everything runs in your browser — nothing is uploaded.
Copy or download the TOML
Get TOML ready for Cargo.toml, pyproject.toml, Pipfile, hugo.toml, or any tool that accepts TOML v1.0.
FAQ
Got questions?
The most common scenarios are: migrating Python projects from requirements.txt + setup.cfg (legacy format) to pyproject.toml (the modern standard defined by PEP 517/518/621), where some configuration may exist in YAML (such as CI/CD workflows) and you want to normalize configuration sections to TOML. Also common when migrating Jekyll sites (YAML front matter) to Hugo (preferred TOML front matter). Finally, teams adopting Rust often have CI/CD configurations in YAML (GitHub Actions) that need to be reflected in Cargo.toml for managing features or workspace members.
docker-compose.yml defines services, networks, and volumes in YAML. While there is no native TOML equivalent for Docker Compose (Docker only accepts YAML for its Compose format), converting docker-compose.yml to TOML can be useful as an intermediate representation: some Rust projects use TOML as their own infrastructure configuration (for example, server configurations with tokio, actix-web, or tauri), and having the same service structure in TOML facilitates integration. The conversion generates valid TOML with [[services]] sections for arrays of objects.
GitHub Actions workflows (.github/workflows/*.yml) have a specific structure (on, jobs, steps) that does not directly correspond to pyproject.toml's structure ([project], [tool.X], [build-system]). However, it is common to want to extract parts of the workflow — such as the Python version matrix, test dependencies, or tool configuration — to include in pyproject.toml. This tool converts the full YAML to structural TOML; from the resulting TOML you can select and adapt the relevant sections to add to your pyproject.toml.
The reverse process of Hugo→Jekyll: Jekyll's YAML front matter is delimited by --- at the start and end of the Markdown file. To migrate to Hugo with TOML front matter, extract the YAML block between the ---, convert it to TOML with this tool, and replace the --- delimiters with +++. Common fields (title, date, tags, categories, draft) translate directly. Jekyll-specific permalinks and layouts may need manual mapping to Hugo equivalents (url, type, layout).
Some YAML features have no direct mapping to TOML. YAML anchors and aliases (&anchor and *alias) are resolved before conversion, so the resulting TOML contains the expanded values, not references. Multiple YAML documents (separated by ---) have no TOML equivalent, as TOML is always a single document. Keys with special types (dates as map keys, keys with special characters) may require quoting in TOML. YAML null values (~ or null) are represented as empty strings or omitted in TOML, since TOML has no native null type (TOML 1.0 does not include null).
The generated TOML is syntactically valid per the TOML 1.0 specification and can be parsed by toml-rs (the Rust parser used by Cargo) or other standard TOML libraries. However, semantic compatibility with Cargo.toml depends on whether the input YAML correctly models the structure of a Cargo manifest: [package], [dependencies], [dev-dependencies], [[bin]], [[lib]], and so on. If your YAML already models this structure, the resulting TOML will be a valid Cargo.toml. If it comes from a different source (such as docker-compose.yml), the resulting TOML will need manual adaptation.
Convert YAML to TOML: migrating Docker and GitHub Actions to the Rust and Hugo ecosystem
Converting YAML to TOML is a less common flow than the reverse direction, but it has well-defined use cases in the modern development ecosystem. The most relevant is the adoption of TOML as the configuration standard in Python: pyproject.toml, defined by PEP 518 in 2016 and extended by PEP 517 (build system), PEP 621 (project metadata, 2021), and PEP 660 (editable builds), has progressively replaced setup.py, setup.cfg, and requirements.txt as the central configuration for modern Python projects. Tools like Poetry, Hatch, Flit, and PDM use pyproject.toml as their source of truth. If an existing Python project has part of its configuration in YAML — for example, supported Python versions defined in a GitHub Actions workflow, or tox configuration in YAML — converting it to TOML to centralize it in pyproject.toml is a maintainability improvement.
In the Rust ecosystem, Cargo.toml is the heart of the project: it defines the crate name, version (following Semantic Versioning), authors, Rust edition (2015, 2018, 2021, 2024), dependencies with semver versions, optional crate features, targets (binaries, libraries, examples, tests, benchmarks), and workspace configuration for monorepo projects. When a team adopts Rust for a new service in an infrastructure that already uses YAML extensively (docker-compose.yml for local development, Kubernetes manifests for production, GitHub Actions for CI/CD), they may need to extract parts of that YAML configuration to include in Cargo.toml. The most practical example: the GitHub Actions workflow defines the Rust version matrix to test against (stable, beta, nightly); that information may want to be reflected in the workspace's Cargo.toml.
Content migration between static site generators is the most concrete scenario for YAML→TOML. Jekyll, created by Tom Preston-Werner in 2008 and the engine behind GitHub Pages, popularized the concept of YAML front matter delimited by --- in Markdown files. Hugo, the fastest static site generator (written in Go, with typical build times of milliseconds for thousands of pages), adopted TOML as its preferred front matter format in early versions, though it also supports YAML and JSON. Migrating a site from Jekyll to Hugo — a popular migration among developers seeking better performance for large sites — requires converting the YAML front matter of each Markdown file to TOML format with +++ delimiters. For a site with hundreds of posts, this is automated with Python scripts (PyYAML + toml) or Node.js (js-yaml + @iarna/toml), using this tool to validate the conversion for individual cases.