JSON / YAML Formatter

Format, validate, and convert between JSON and YAML instantly

100% Client-Side Processing

Your data is processed entirely in your browser. Nothing is sent to any server.

Output:
Indent:
Input
Output
Formatted output will appear here...

About This Tool

Paste in messy JSON or YAML and get it formatted nicely, or convert between the two. Handy when you're working with API responses, config files, or just need to make sense of a blob of data someone sent you.

JSON vs YAML

JSON (JavaScript Object Notation) and YAML (YAML Ain't Markup Language) both represent structured data, but they serve different audiences. JSON is designed for machines — strict syntax, easy to parse, and the default format for web APIs. YAML is designed for humans — clean, readable, and the preferred format for configuration files.

JSON

{
  "server": {
    "host": "netoz.au",
    "port": 443,
    "ssl": true,
    "locations": [
      "/api",
      "/dashboard"
    ]
  }
}

YAML (equivalent)

server:
  host: netoz.au
  port: 443
  ssl: true
  locations:
    - /api
    - /dashboard

Key differences

Syntax

JSON uses braces, brackets, and quotes. YAML uses indentation and minimal punctuation.

Comments

JSON has no comment syntax. YAML supports # comments, making it better for documented configs.

Data types

JSON supports strings, numbers, booleans, null, arrays, and objects. YAML adds dates, timestamps, and multi-line strings.

In practice, most teams use both. APIs return JSON because every language has a built-in JSON parser. Configuration files use YAML because it's easier to read and edit by hand. Docker Compose, Kubernetes manifests, Ansible playbooks, GitHub Actions workflows, and CI/CD pipelines all use YAML. Understanding both formats — and being able to convert between them — is essential for modern development and infrastructure work.

Validation Rules

Both formats have strict rules that must be followed for valid documents. A single misplaced character can cause parsing failures that are difficult to debug without a validator.

JSON Validation Rules

  • • All strings must use double quotes — single quotes and unquoted keys are invalid
  • • No trailing commas after the last item in an array or object
  • • No comments of any kind — // comment and /* comment */ are syntax errors
  • • Numbers cannot have leading zeros (use 0.5 not .5, use 10 not 010)
  • • The root element must be an object {} or array []
  • • Special characters in strings must be escaped: \", \\, \n, \t

YAML Validation Rules

  • • Indentation must use spaces only — tabs are not allowed and will cause a parse error
  • • Consistent indentation within the same level (typically 2 spaces)
  • • Colons in key-value pairs must be followed by a space: key: value not key:value
  • • Strings containing special characters (: # [ ] {} , & * ? | - < > = ! % @) must be quoted
  • • Boolean values are case-insensitive: true, True, TRUE, yes, on are all truthy
  • • The "Norway problem": country code NO is parsed as boolean false — quote it: "NO"

Common pitfall: YAML type coercion

YAML automatically interprets unquoted values as their "best guess" type. The string 3.10 becomes the float 3.1 (losing the trailing zero). Version numbers like 1.0 become floats instead of strings. Always quote values that look like numbers but aren't: "3.10", "1.0".

Configuration File Examples

Both JSON and YAML are used extensively in infrastructure and application configuration. Here are real-world examples you might encounter when managing web hosting, CI/CD pipelines, or containerised applications.

Docker Compose (YAML)

services:
  web:
    image: nginx:alpine
    ports:
      - "443:443"
    volumes:
      - ./html:/usr/share/nginx/html
      - ./certs:/etc/ssl/certs
    environment:
      - SERVER_NAME=netoz.au
    restart: unless-stopped

  db:
    image: postgres:16
    environment:
      POSTGRES_DB: netoz_app
      POSTGRES_USER: admin
      POSTGRES_PASSWORD_FILE: /run/secrets/db_pass
    volumes:
      - pgdata:/var/lib/postgresql/data

GitHub Actions Workflow (YAML)

name: Deploy to production
on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and deploy
        run: |
          npm ci
          npm run build
          rsync -avz ./dist/ deploy@netoz.au:/var/www/html/

package.json (JSON)

{
  "name": "netoz-dashboard",
  "version": "2.1.0",
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start"
  },
  "dependencies": {
    "next": "^15.0.0",
    "react": "^19.0.0"
  }
}

Kubernetes Deployment (YAML)

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: netoz-web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: netoz-web
  template:
    spec:
      containers:
        - name: web
          image: netoz/web:latest
          ports:
            - containerPort: 3000
          resources:
            limits:
              memory: "256Mi"
              cpu: "500m"

Generate web server configurations with the Web Server Config Generator, create systemd service files with the Systemd Unit Generator, or decode JWT tokens with the JWT Decoder.