Is my workflow YAML sent to a server?

No. Validation runs entirely in your browser using JavaScript. Your workflow definitions — including secrets references, repository names, and runner labels — never leave your device.

What does the linter check?

The linter validates: presence of the required "on" and "jobs" top-level keys, each job having a "runs-on" key, each step having either "uses" or "run" (but not both), proper indentation (detected via YAML parsing), and common mistakes like using "steps" without "jobs" or empty job definitions.

Does this replace the GitHub Actions schema validator?

No. For full schema validation, use the VS Code GitHub Actions extension or the actionlint tool in CI. This tool provides a quick in-browser sanity check before you push.

Why is my workflow failing on GitHub but passing here?

This linter checks structural validity, not runtime semantics. Issues like invalid runner labels, secret access restrictions, or environment protection rules are only caught by the GitHub Actions runtime.

What is the "on" key and how do I format it?

The "on" key defines workflow triggers. It can be a string (on: push), a list (on: [push, pull_request]), or a mapping (on: { push: { branches: [main] } }). Note: "on" is a YAML reserved word — always quote it as "on" in editors that flag it.

Can I validate reusable workflows?

Yes. Reusable workflows use "on: workflow_call" and may have an "inputs" section. The linter validates the same structural rules.

What is the difference between "uses" and "run" in a step?

"uses" references a GitHub Action from the Marketplace or a local path (e.g. actions/checkout@v4). "run" executes a shell command. A step must have exactly one of these — not both, not neither.

How do I pass environment variables to a step?

Use the "env" key at the step level: env: { MY_VAR: ${{ secrets.MY_SECRET }} }. For job-wide variables, use the "env" key at the job level. For workflow-wide variables, use the top-level "env" key.

GitHub Actions YAML Linter

Paste a GitHub Actions workflow YAML file and get instant structural validation. Catches missing required keys and common step mistakes before you push.

100% client-side · no upload

tool.github-actions-yaml-lint.label-workflow-yaml

Validation results

Click "Validate Workflow" to see results.

How to validate a GitHub Actions workflow

Paste your .github/workflows/*.yml file content into the editor.
Click Validate Workflow or wait for auto-validation.
Review each error and warning in the results panel.
Fix the issues and re-validate until no errors remain.
For full validation, also run actionlint locally or in CI.

Common use cases

Pre-push check: Catch structural issues before GitHub rejects the workflow file.
Onboarding: Validate example workflows when learning GitHub Actions syntax.
Code review: Paste a colleague's workflow to spot issues during review.

Related tools: Dockerfile Linter · .env Formatter · YAML Formatter · All DevOps Tools

Frequently Asked Questions

Is my workflow YAML sent to a server?: No. Validation runs entirely in your browser using JavaScript. Your workflow definitions — including secrets references, repository names, and runner labels — never leave your device.
What does the linter check?: The linter validates: presence of the required "on" and "jobs" top-level keys, each job having a "runs-on" key, each step having either "uses" or "run" (but not both), proper indentation (detected via YAML parsing), and common mistakes like using "steps" without "jobs" or empty job definitions.
Does this replace the GitHub Actions schema validator?: No. For full schema validation, use the VS Code GitHub Actions extension or the actionlint tool in CI. This tool provides a quick in-browser sanity check before you push.
Why is my workflow failing on GitHub but passing here?: This linter checks structural validity, not runtime semantics. Issues like invalid runner labels, secret access restrictions, or environment protection rules are only caught by the GitHub Actions runtime.
What is the "on" key and how do I format it?: The "on" key defines workflow triggers. It can be a string (on: push), a list (on: [push, pull_request]), or a mapping (on: { push: { branches: [main] } }). Note: "on" is a YAML reserved word — always quote it as "on" in editors that flag it.
Can I validate reusable workflows?: Yes. Reusable workflows use "on: workflow_call" and may have an "inputs" section. The linter validates the same structural rules.
What is the difference between "uses" and "run" in a step?: "uses" references a GitHub Action from the Marketplace or a local path (e.g. actions/checkout@v4). "run" executes a shell command. A step must have exactly one of these — not both, not neither.
How do I pass environment variables to a step?: Use the "env" key at the step level: env: { MY_VAR: ${{ secrets.MY_SECRET }} }. For job-wide variables, use the "env" key at the job level. For workflow-wide variables, use the top-level "env" key.

Report a problem with this tool