ForHosting KIT · Data & Files

YAML to JSON

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.

● StableFree · in your browser

Run — free How it works & API

Use it from WebAPIEmailApp soonTelegram soon

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.

What you can do with it

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.

FAQ

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.

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.

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.

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

POSThttps://api.kit.forhosting.com/data/yaml-json

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, and soon from our app, email and Telegram.

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 &#39;{"input":"…"}'

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({
    "input": "…"
  })
});
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[&#39;KIT_KEY']}"},
    json={
    "input": "…"
},
)
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" => &#39;{"input":"…"}',
  ],
]));
$task = json_decode($res, true);

body := bytes.NewBufferString(`{"input":"…"}`)
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

{
  "input": "…"
}

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

Per request$0.002

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.

Read the full KIT documentation →

Run — free