Kubernetes YAML Validator

Check manifests against strict per-kind Kubernetes schemas with line-anchored findings — entirely on this device.

Paste one or more Kubernetes manifests and they are checked against strict per-kind schemas pinned at v1.33.1 — unknown fields are violations, not noise. Validation runs on this device; beyond the page's own code, the only download is the per-kind schema file, fetched from this site.

Kubernetes manifests (multi-document YAML)

The first check of each kind downloads its schema from this site once — 16 kinds vendored at v1.33.1, 17 KB to 767 KB each. Your manifest is never part of that request.

Vendored kinds and download sizes

Loading the kind list…

Documents

Paste manifests, then press Validate.

Press ? for shortcuts

Do it offline:$

How to use it

Paste manifest YAML into the editor, or load the sample — a Deployment carrying a field typo that lenient tools accept.
Press Validate. The first check of each kind downloads its schema from this site once, with the size shown before anything moves.
Read the per-document groups: every violation carries the rule that fired, the JSON path, and a line link that jumps the editor there.
Copy or download the report to hand a verdict to a teammate — share links carry the schema version only, never your YAML.

Paste Kubernetes manifests — one document or a whole --- separated file — and each is checked against a strict schema for its exact apiVersion and kind, pinned at v1.33.1. Strict means unknown fields fail: a misspelled key is a violation with a line number, not silent noise. Checking runs on this device; beyond the page's own code, the only request fetches the schema file from this site, and your manifest is never in it.

Examples

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.29

Valid — no schema violations found

A minimal Deployment that conforms. The verdict is worth having before a commit: it rules out the whole class of structural mistakes without touching a cluster.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replica: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.29

line 6:3 · /spec — must NOT have additional properties

spec.replica instead of spec.replicas. A generic YAML check calls this file fine; strict mode anchors the violation at the misspelled key itself, so the fix is one keystroke away.

apiVersion: v1
kind: Pod
metadata:
  name: web
spec:
  containers:
    - name: web
      image: nginx:1.29
      ports:
        - containerPort: "80"

line 10:26 · /spec/containers/0/ports/0/containerPort — must be integer

A quoted port is a string, and the API server would reject it at apply time. The type rule fires at the offending scalar, not at the document root.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: web
          image: nginx:1.29
---
apiVersion: v1
kind: Service
metadata:
  name: web
spec:
  selector:
    app: web
  ports:
    - port: 80
      targetPort: 8080

2 documents — all valid

A Deployment and its Service in one paste. Each document is classified by its own apiVersion and kind, checked against its own schema, and reported as its own group with absolute line numbers.

Every example on this page is executed against the same engine that powers the tool, on every build.

Gotchas worth knowing

Strict mode is the point

These schemas set additionalProperties to false, so a typo like spec.replica or an indentation slip that hoists a key one level up becomes a positioned violation. That is the deliberate difference from a generic YAML syntax check, which only asks whether the text parses — both checks have a job, and this page does the Kubernetes-aware one.

kubectl cannot do this offline

Client-side kubectl validation still asks a cluster for its OpenAPI document: run kubectl apply --dry-run=client --validate=true with no reachable cluster and it fails with "failed to download openapi: Get http://localhost:8080/openapi/v2 … connection refused" — executed on 2026-08-18 with a v1.36.1 client. Pinned schemas are what make a no-cluster, no-upload check possible at all.

What is deliberately out of scope

No custom resources: a CRD kind gets a typed refusal naming the 16 vendored kinds, and kubeconform with -schema-location remains the right tool for company-internal schemas. No admission or defaulting semantics — a structurally legal manifest can still be rejected by a webhook. And format annotations such as int64 or date-time are not asserted, matching kubeconform's default posture; structure and types are what strict mode enforces.

Common errors

No v1.33.1 schema ships here for kind "Rollout" (argoproj.io/v1alpha1) — the 16 vendored kinds are: ConfigMap, CronJob, DaemonSet, Deployment, HorizontalPodAutoscaler, Ingress, Job, Namespace, NetworkPolicy, PersistentVolumeClaim, Pod, ReplicaSet, Secret, Service, ServiceAccount, StatefulSet.: Custom and aggregated API kinds have no schema in the vendored set, so the tool refuses honestly instead of inventing a verdict. Other documents in the same paste are still checked.
This document has no apiVersion field — a Kubernetes manifest names its API group and version (for example apps/v1).: Classification needs both coordinates: apiVersion picks the API group and version, kind picks the schema. A bare fragment copied out of a Helm template usually trips this.
Input is 524,289 bytes — larger than the 524,288-byte (512 KiB) limit for this tool.: The cap is measured in bytes and refused before any parsing, so a runaway paste cannot stall the page. Manifest files sit far below it; split generated bundles if you ever hit it.

FAQ

What does strict validation catch that a lenient check misses?

Three classes: unknown fields (typos, wrong nesting levels), wrong types (a quoted number where an integer belongs), and missing required fields. A lenient checker accepts any well-formed YAML; the API server does not, and strict per-kind schemas move that disagreement onto your screen before an apply.

Why are CRDs and operator kinds refused?

A CustomResourceDefinition's schema lives in the cluster that defines it — there is no truthful pinned copy to ship here. Rather than validate against nothing, the tool names the 16 kinds it vendors and stops. For CRD-heavy repositories, kubeconform can point -schema-location at your own generated schemas.

Which Kubernetes version do the schemas track, and why one?

Every schema is pinned at v1.33.1 from a single upstream commit, named in the citations and shown in the tool itself. One pinned version keeps the verdict reproducible — the same paste gives the same answer next month — and the schema set is built so further versions can be added as data without changing how the tool works.

Keyboard shortcuts

/: Focus the manifest editor
⌘/Ctrl + Enter: Validate the pasted manifests
⌘/Ctrl + S: Download the validation report
⌘/Ctrl + C: Copy the report with an empty selection
⌘/Ctrl + Shift + C: Copy the report
t: Cycle the color theme
? or ⌘/Ctrl + /: Open this shortcut list
Esc: Close dialogs

Nothing you paste here leaves this tab. State only ever travels in links you explicitly create.

Kubernetes JSON schemas — yannh/kubernetes-json-schema @ c8f4e61c, v1.33.1-standalone-strict (Apache-2.0) · Kubernetes API reference — the fields these schemas model · kubeconform — native validator with -schema-location for CRDs · kubectl reference — client-side commands and their limits

Last reviewed: 2026-08-18