YAML to JSON
Convert YAML into the curly-brace format apps read, or back again: in the example, a server block with host example.com and port 8080 keeps its nesting, and 8080 stays a number. Comments that cannot survive the trip are reported, not lost silently. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Runs in your browser. Free, unlimited — your data never leaves this page.
convert either way, free online
Two ways of writing the same data
YAML, first published in 2001, was built to be read and edited by people: indentation instead of brackets, and room for comments next to each setting. The curly-brace format that most applications read is the opposite, strict and easy for programs but tiring to edit by hand. Kubernetes manifests, GitHub Actions workflows and docker-compose files are all YAML, which dashboards, validators and configuration editors built for the other format cannot read directly. Plenty of settings also start life in the brace format and have to become YAML as soon as they reach a deployment pipeline that only speaks YAML. One converter covers both trips.
What survives the trip, and what does not
Structure and types travel intact. In the example, the server group keeps its host, example.com, and its port, 8080, nested inside it; the port stays a number and the active setting stays true. Comments are different: the brace format has no place for them, so they cannot come along. Instead of disappearing without a word, they are listed in a short report, together with certain YAML anchors that do not survive either. The direction is worked out from what you paste, or you can set it yourself. The classic surprise is converting a commented file and back again, then finding the notes gone, so keep the original YAML when those comments matter.
FAQ
Does it support multi-document YAML files?
Yes, YAML files with multiple documents separated by --- are handled, converting each document and returning them as a structured result.
Will indentation or formatting errors break the conversion?
Malformed YAML fails cleanly with a clear error identifying the problem rather than guessing at a broken structure, and you are not charged for a failed request.
What happens to YAML comments?
They have no equivalent in the other format, so they cannot travel with the data. Instead of vanishing silently, they are reported back to you, together with certain anchors that cannot survive the conversion either.
How does it know which way to convert?
From what you submit: paste YAML and you get the curly-brace format, paste the curly-brace format and you get YAML. If you prefer not to rely on that, you can also set the direction yourself.
Do numbers and true or false values keep their type?
Yes. In the example, the port 8080 comes out as a number, the active setting stays a true value and example.com stays text, all inside the same nested server group.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/data/yaml-json \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"yaml":"a: 1","json":{"a":1}}'const res = await fetch("https://api.kit.forhosting.com/data/yaml-json", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"yaml": "a: 1",
"json": {
"a": 1
}
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/data/yaml-json",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"yaml": "a: 1",
"json": {
"a": 1
}
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/data/yaml-json", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"yaml":"a: 1","json":{"a":1}}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"yaml":"a: 1","json":{"a":1}}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/data/yaml-json", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"yaml": "a: 1",
"json": {
"a": 1
}
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "data.yaml_json",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 25 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
YAML reads beautifully to humans and terribly to most parsers outside the DevOps toolchain, while JSON is the opposite — this endpoint moves cleanly between them in either direction. It also tells you, honestly, what got left behind: YAML comments have no JSON equivalent, so instead of silently vanishing, they're reported back to you.
One tool, two directions
A Kubernetes manifest, a GitHub Actions workflow, a docker-compose file — all YAML, all things a JSON-based dashboard, validator or config editor can't read natively. Meanwhile plenty of application config starts life as JSON and needs to become YAML the moment it lands in a CI pipeline that only speaks that format. data.yaml_json handles both trips in a single endpoint: send YAML and get JSON, or send JSON and get YAML, with the direction inferred from what you submit or set explicitly in the request.
What happens to your request
POST your document to /data/yaml-json, and a task_id comes back immediately while the conversion runs in the background. When it's done, the converted document — plus a short report of anything YAML-specific that couldn't survive the trip to JSON, like comments and certain anchors — arrives by signed webhook or waits behind a signed link valid for 24 hours.
Why comments are the honest exception
YAML, first published in 2001 and built to be readable by people editing config files by hand, allows inline comments as a first-class feature — a line starting with # explaining why a value is set the way it is. JSON, designed purely as a data-interchange format, has no comment syntax at all, by design, so there's no destination for that text to go. Rather than pretend nothing was lost, the endpoint reports which comments existed and roughly where, so you know exactly what changed instead of discovering it later when someone asks where the explanatory note went.
How it fits an automated pipeline
Config-heavy teams often keep human-edited YAML as the source of truth and need a validated JSON copy for tooling, or the reverse: a JSON config store that needs to export human-readable YAML for a repository. Running that conversion through an async, per-request-priced endpoint means a CI step can submit a file, move on to the next stage, and pick up the result by webhook without blocking the pipeline on a conversion step, and a failed parse is never billed, which matters when config files are edited by hand and occasionally malformed.
Integration use cases
Kubernetes manifest tooling
A dashboard converts YAML Kubernetes manifests to JSON so its JSON-schema validator and diff viewer can process them without a custom YAML parser.
CI/CD pipeline config export
A platform stores pipeline definitions internally as JSON and converts them to YAML on export so they can be committed to a repository in the format the CI runner expects.
docker-compose to JSON for automation
An infrastructure tool converts docker-compose YAML files to JSON to feed them into a JSON-based provisioning script.
Preserving comment context during audits
A config-review tool converts YAML to JSON for automated checks while keeping the reported comment list so reviewers still see the original human notes.
Technical questions
How do I convert YAML to JSON with the API?
POST your YAML or JSON document to /data/yaml-json, save the returned task_id, and receive the converted document by webhook or a signed link valid for 24 hours.
Is the YAML to JSON API free?
No, there is no free tier or trial; it costs $0.002 per request, and a failed conversion is never charged.
Does it convert JSON to YAML too?
Yes, the same endpoint converts in either direction, detecting the input format or following an explicit direction you set in the request.
What happens to YAML comments when converting to JSON?
They can't be represented in JSON, since JSON has no comment syntax, so instead of disappearing silently the endpoint reports which comments existed and where.
Can I convert many config files in bulk?
Yes, submit one async task per file and collect each result by webhook as it finishes, which suits CI pipelines processing many configs at once.
Is my YAML or JSON data stored after conversion?
No, source files and results are deleted after the retention window and are never used for training.