GitHub Actions YAML Linter
Lint a GitHub Actions workflow YAML file in your browser. Catches syntax errors (tabs, unclosed quotes, duplicate keys), missing required keys (on, jobs), jobs without runs-on or steps, and unpinned or @main/@master action references — reported as a severity summary and a line-by-line issues table.
Input
Output
Summary
| Severity | Count |
|---|---|
| No data yet | |
Issues
| Line | Severity | Message |
|---|---|---|
| No data yet | ||
Guides
Paste a GitHub Actions workflow file and get an instant, line-by-line report of what is wrong with it — before you push a broken .github/workflows/*.yml and wait on a red run. This linter parses your workflow in the browser and checks it against the rules that actually break Actions builds, then groups the findings into a severity summary and a detailed issues table.
What it checks
YAML syntax. The single most common cause of a failed workflow is malformed YAML. The linter flags tab characters used for indentation (YAML requires spaces), unclosed quotes, duplicate keys within the same mapping, and lines whose indentation does not align with the surrounding block.
Required structure. Every workflow needs an on: trigger and a jobs: block. Each normal job needs a runs-on: runner and at least one entry under steps:. Reusable-workflow jobs (uses:) must not declare runs-on or steps. Missing or misplaced keys are reported as errors with the job name so you know exactly where to look.
Action pinning and security. Referencing an action by a moving branch — actions/checkout@main or @master — means your build silently changes whenever that branch does, and it is a supply-chain risk. Those references are flagged as warnings. Pinning to a version tag such as @v4 earns a best-practice hint suggesting a full commit SHA for third-party actions. An action with no @ref at all is an error.
Best-practice hints. With hints enabled, the linter also nudges you toward timeout-minutes on long-running jobs and away from deprecated workflow commands like ::set-output:: and ::set-env::. Turn hints off to see only hard errors and warnings.
How to use it
- Copy the contents of your workflow file and paste it into the input box.
- Read the summary table for a quick error/warning/hint count.
- Work through the issues table top to bottom — each row gives the line number, severity, and a plain-English message.
- Fix, re-paste, and repeat until the count is zero.
The issues table can be copied or downloaded as CSV for sharing in a pull-request review.
Does my workflow get uploaded anywhere?
No. All parsing and linting run entirely in your browser using a lightweight, purpose-built YAML parser. Your workflow — including any secret names or internal job details — never leaves your machine.
Is this a full YAML validator?
It targets the GitHub Actions workflow schema specifically, so it understands jobs, steps, runners, triggers, and permissions rather than treating your file as generic YAML. That focus is what lets it give actionable, Actions-aware feedback instead of a bare "line 12: bad syntax".