JSON to YAML for Kubernetes – Convert kubectl Output to Manifests

kubectl get deployment my-app -o json returns a fully specified Kubernetes resource — but the output includes server-generated fields (resourceVersion, uid, creationTimestamp) that break re-application if left in. Converting that JSON to YAML and stripping the server metadata gives you a clean manifest you can commit to version control, apply to other clusters, or use as a Helm values base. A JSON to YAML converter handles the structural transformation in one step.

This pattern — fetch from the API, convert format, clean metadata, commit — is how teams reverse-engineer live cluster state into source-of-truth manifests. It is also how platform engineers bootstrap Helm chart values from existing deployments without rewriting the entire resource by hand.

// kubectl get deployment my-app -o json (abbreviated)
{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "my-app",
    "namespace": "production",
    "uid": "f47ac10b-58cc-4372-a567-0e02b2c3d479",
    "resourceVersion": "1234567",
    "creationTimestamp": "2024-01-15T10:00:00Z"
  },
  "spec": {
    "replicas": 3,
    "selector": { "matchLabels": { "app": "my-app" } }
  }
}

# Converted to YAML — then remove the server-managed fields:
apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-app
  namespace: production
  # Remove: uid, resourceVersion, creationTimestamp, managedFields
spec:
  replicas: 3
  selector:
    matchLabels:
      app: my-app

Why Convert Kubernetes JSON to YAML?

Kubernetes stores all resources internally as JSON. The kubectl CLI returns JSON when you use -o json. But Kubernetes manifests in version control are almost universally YAML — for the same reasons config files generally are: comments, readability, and compatibility with GitOps tools like ArgoCD and Flux.

Converting the live resource JSON to YAML enables two workflows:

• Reverse-engineering manifests from a live cluster. If a deployment was created by hand or by a tool that did not leave source files, fetching the live resource as JSON and converting to YAML produces a starting manifest. After cleaning server metadata, the file becomes a valid source-of-truth manifest.
• Building Helm values from existing deployments. When migrating an existing deployment to Helm, converting the live resource to YAML and extracting the variable fields into a values.yaml is faster than writing the values file from scratch.

For the reverse operation — converting a YAML manifest back to JSON for API calls — see our guide on YAML to JSON conversion. For validating the resulting YAML, use the YAML Validator.

Fields to Remove After Conversion

The JSON returned by kubectl get includes fields that the Kubernetes API server adds and manages. These fields must be removed before committing the manifest or applying it to another cluster.

# Remove these fields from converted kubectl output:
metadata:
  uid: f47ac10b-...           # server-assigned, remove
  resourceVersion: "1234567"  # server-managed, remove
  creationTimestamp: "2024-..." # server-assigned, remove
  generation: 5               # server-managed, remove
  managedFields: [...]        # audit trail, remove entirely

status: {}                    # status subresource, remove

# Keep:
metadata:
  name: my-app
  namespace: production
  labels: { ... }
  annotations: { ... }        # keep app annotations, remove kubectl.kubernetes.io/*

• metadata.uid — the server-assigned unique ID for this specific resource instance. Remove it so the manifest can create a new resource, not reference a specific existing one.
• metadata.resourceVersion — used for optimistic concurrency by the API. Remove it before applying to a different cluster or re-applying from scratch.
• metadata.managedFields — verbose audit data about which fields were set by which controller. Remove entirely; it adds noise without value in version control.
• status — the current live state of the resource. Manifests define desired state; status is server-managed. Remove the entire block.

How to Convert and Clean the Manifest

Using the DevToolBox JSON ↔ YAML Converter to produce a clean Kubernetes manifest takes under two minutes.

1. Run kubectl get <resource> <name> -o json and copy the output.
2. Open the converter in your browser. No account, no install.
3. Paste the JSON and select JSON → YAML.
4. Copy the YAML output into your text editor.
5. Delete the server-managed fields listed above: uid, resourceVersion, creationTimestamp, generation, managedFields, and the status block.
6. Validate the cleaned YAML with the YAML Validator before committing.

DevToolBox tools run entirely in your browser — nothing you paste is transmitted to any server.

Common Conversion Errors

• Leaving resourceVersion in the manifest. Applying a manifest that includes resourceVersion to a cluster where that version does not match causes the API to reject the apply with a conflict error. Always remove it before applying to a different cluster or environment.
• Port numbers converted as integers. Kubernetes resource quantities like "8080" in JSON may convert to the integer 8080 in YAML. For fields that expect a string (some annotation values, for example), verify the type after conversion.
• Large managedFields blocks obscuring the important content. Some converted manifests have managedFields arrays that are hundreds of lines long. Remove them before reviewing the rest of the file — they add no value in a version-controlled manifest.

Frequently Asked Questions

Conclusion

Converting Kubernetes JSON to YAML is a routine step in the GitOps workflow — fetching live state, converting format, removing server metadata, and committing the result. The converter handles the structural transformation; the field cleanup is manual but predictable. The same four fields need to be removed every time: uid, resourceVersion, managedFields, and status.

If you need a fast JSON to YAML converter that handles Kubernetes resource structures correctly, DevToolBox does exactly that. DevToolBox tools run entirely in your browser — no signup, no install, nothing sent to a server.