DevToys Pro

free web developer tools

Blog
Rate us:
Try browser extension:
← Back to Blog

Config Workflow: Convert YAML↔JSON → Validate → Diff Changes

11 min read

You receive a Kubernetes config in YAML, need to validate it, convert it to JSON for an API call, then compare changes between production and staging versions. This guide walks through a complete configuration management workflow using three interconnected tools.

The Scenario: Kubernetes Config Migration

Problem: You're migrating a Kubernetes deployment between environments. You need to:

  1. Convert the production YAML config to JSON for API deployment
  2. Validate both YAML and JSON syntax
  3. Compare staging and production configs to identify differences
  4. Document changes for the deployment log

Production Config (YAML)

apiVersion: v1
kind: Service
metadata:
  name: web-service
  namespace: production
spec:
  selector:
    app: web
    tier: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 8080
  type: LoadBalancer
  sessionAffinity: ClientIP

Step 1: Convert YAML to JSON

Tool: JSON/YAML Converter

Goal: Convert YAML configuration to JSON format for API deployment or programmatic processing.

Actions

  1. Open the JSON/YAML Converter
  2. Paste the YAML config into the input area
  3. Click "YAML → JSON" conversion
  4. Copy the JSON output

JSON Output

{
  "apiVersion": "v1",
  "kind": "Service",
  "metadata": {
    "name": "web-service",
    "namespace": "production"
  },
  "spec": {
    "selector": {
      "app": "web",
      "tier": "frontend"
    },
    "ports": [
      {
        "protocol": "TCP",
        "port": 80,
        "targetPort": 8080
      }
    ],
    "type": "LoadBalancer",
    "sessionAffinity": "ClientIP"
  }
}

Result: Valid JSON ready for Kubernetes API calls or JSON-based configuration management tools.

Step 2: Validate Syntax

Tool: JSON Formatter

Goal: Verify the converted JSON has no syntax errors before deployment.

Actions

  1. Open the JSON Formatter
  2. Paste the converted JSON
  3. Look for syntax error indicators (red underlines, error messages)
  4. If valid, format with proper indentation

Validation Result

 Valid JSON
 Properly formatted
 No trailing commas
 All quotes balanced
 Ready for deployment

Common validation issues caught:

  • Trailing commas in arrays or objects
  • Unquoted keys
  • Single quotes instead of double quotes
  • Missing commas between properties
  • Comments (not allowed in strict JSON)

Step 3: Compare Configurations

Tool: Text Comparer (Diff)

Goal: Identify differences between staging and production configs before deploying changes.

Staging Config (Different Settings)

apiVersion: v1
kind: Service
metadata:
  name: web-service
  namespace: staging
spec:
  selector:
    app: web
    tier: frontend
  ports:
    - protocol: TCP
      port: 80
      targetPort: 3000
  type: ClusterIP
  sessionAffinity: None

Actions

  1. Open the Text Comparer
  2. Paste production config in left panel
  3. Paste staging config in right panel
  4. Review highlighted differences
  5. Document changes for deployment log

Diff Output (Key Changes)

Line 4: namespace
  Production: production
  Staging:    staging

Line 12: targetPort
  Production: 8080
  Staging:    3000

Line 14: type
  Production: LoadBalancer
  Staging:    ClusterIP

Line 15: sessionAffinity
  Production: ClientIP
  Staging:    None

Result: Clear view of configuration differences for review before deployment.

Complete Workflow Summary

1. Convert Format
   Input: YAML config (human-readable)
   Tool: JSON/YAML Converter
   Output: JSON config (API-ready)

2. Validate Syntax
   Input: JSON config
   Tool: JSON Formatter
   Output: Valid JSON confirmed

3. Compare Versions
   Input: Production config vs Staging config
   Tool: Text Comparer
   Output: List of differences (namespace, ports, type, affinity)

Final Result: Validated JSON ready for deployment + documented changes

Advanced Use Cases

Case 1: Merge Multiple Config Files

Scenario: Combine base config with environment-specific overrides.

# base-config.yaml
app:
  name: my-service
  version: 1.0.0

# production-overrides.yaml
app:
  replicas: 5
  resources:
    memory: 2Gi

# Convert both to JSON, merge programmatically, then validate

Case 2: Extract Environment Variables

Extract env vars from config for .env file generation:

# YAML config with env section
env:
  - name: DATABASE_URL
    value: postgres://localhost:5432/db
  - name: API_KEY
    value: abc123

# Convert to JSON, extract with JSONPath:
$.env[*].['name', 'value']

# Generate .env file
DATABASE_URL=postgres://localhost:5432/db
API_KEY=abc123

Case 3: Config Template Validation

Validate config templates before rendering:

# Template with placeholders (YAML)
database:
  host: ${DB_HOST}
  port: ${DB_PORT}
  name: ${DB_NAME}

# Convert to JSON to verify structure
# Validate JSON syntax (ignore placeholder values)
# Replace placeholders programmatically
# Validate final config

Common Configuration Patterns

Pattern 1: Docker Compose → Kubernetes

# docker-compose.yml (YAML)
version: '3.8'
services:
  web:
    image: nginx:latest
    ports:
      - "80:80"
    environment:
      - NODE_ENV=production

# Convert to JSON
# Transform structure to Kubernetes deployment format
# Validate Kubernetes-compatible JSON

Pattern 2: CI/CD Pipeline Configs

# .github/workflows/deploy.yml
name: Deploy
on:
  push:
    branches: [main]
jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v2

# Convert to JSON for programmatic analysis
# Validate workflow syntax
# Compare with previous version to track changes

Pattern 3: API Config Migration

# Legacy JSON config
{
  "api": {
    "version": "v1",
    "endpoints": {...}
  }
}

# Convert to YAML for human editing
# Make changes in YAML (easier to read/edit)
# Convert back to JSON for API
# Validate and compare

Workflow Tips

  1. Always validate after conversion: YAML→JSON conversion can fail with complex YAML features
  2. Use consistent indentation: 2 spaces for YAML, 2-4 for JSON
  3. Compare before deployment: Always diff staging vs production
  4. Document changes: Save diff output in deployment logs
  5. Version control configs: Store both YAML and JSON versions in git

Troubleshooting Common Issues

Issue: YAML Conversion Fails

Cause: Invalid YAML syntax (tabs instead of spaces, incorrect indentation)

Fix: Check YAML syntax rules:

# WRONG: Mixed tabs and spaces
service:
	name: web  # ← Tab character
  port: 80   # ← Spaces

# CORRECT: Consistent spaces
service:
  name: web
  port: 80

Issue: JSON Validation Errors After Conversion

Cause: YAML implicit typing (booleans, nulls, numbers)

Example:

# YAML
enabled: yes  # Converts to boolean true

# JSON
{"enabled": true}  # Valid

# But if YAML has unquoted special values:
version: 1.0  # Number
version: "1.0"  # String

Issue: Diff Shows Too Many Differences

Cause: Whitespace or formatting differences

Fix: Format both files consistently before comparing:

  1. Use JSON Formatter with same indentation settings
  2. Remove trailing whitespace
  3. Use consistent line endings (LF vs CRLF)

Real-World Example: Helm Values

Scenario: Update Helm chart values for different environments.

Step 1: Convert values.yaml to JSON

# values.yaml
replicaCount: 3
image:
  repository: myapp
  tag: v1.2.3
resources:
  limits:
    cpu: 1000m
    memory: 2Gi

Step 2: Modify JSON Programmatically

// Update values
const values = JSON.parse(jsonString);
values.replicaCount = 5;
values.image.tag = "v1.3.0";

// Validate modified JSON
JSON.stringify(values, null, 2);

Step 3: Compare Original vs Modified

# Diff shows:
- replicaCount: 3
+ replicaCount: 5

- tag: v1.2.3
+ tag: v1.3.0

Step 4: Convert Back to YAML for Deployment

replicaCount: 5
image:
  repository: myapp
  tag: v1.3.0
resources:
  limits:
    cpu: 1000m
    memory: 2Gi

Tools Used in This Workflow

Summary

The complete configuration management workflow:

  1. Convert: Transform YAML↔JSON with JSON/YAML Converter
  2. Validate: Check syntax with JSON Formatter
  3. Compare: Diff versions with Text Comparer

This workflow ensures configuration changes are validated, documented, and safely deployed across environments. Essential for DevOps, infrastructure-as-code, and configuration management.