GitHub Actions Workflow Validator
Paste a GitHub Actions workflow and catch mistakes before you push it. This validator parses the YAML, then checks the workflow structure — the on triggers, every job's runs-on and steps, needs references between jobs, and each step's uses or run — and flags common errors plus security and best-practice warnings. It runs entirely in your browser.
How to use the GitHub Actions Workflow Validator
Paste the contents of a workflow file from .github/workflows/ and click validate. The tool first parses the YAML — a syntax error there is reported immediately with the line. It then checks the workflow object: that on and jobs exist, that each job has a runner or a reusable-workflow uses, that steps each have exactly one of run or uses, and that every needs names a real job.
Errors are things GitHub will reject or that will fail at run time; warnings are valid YAML that is usually a mistake or a security risk — an unpinned action, a missing top-level permissions block, or pull_request_target combined with a checkout of untrusted code. Fix the errors first, then weigh the warnings against your situation.
GitHub Actions workflow structure
A GitHub Actions workflow is a YAML file in .github/workflows/. At the top level it needs an on key — the events that trigger it, such as push, pull_request, schedule, or workflow_dispatch — and a jobs map. An optional name labels the workflow in the Actions tab, and an optional top-level permissions block sets the default GITHUB_TOKEN scope for every job.
Each entry under jobs is a job with its own runs-on (the runner label, like ubuntu-latest) and a steps list — unless it calls a reusable workflow with uses, in which case it has no steps of its own. A step does one of two things: it runs a shell command with run, or it invokes an action with uses and passes inputs through with. A step cannot have both. Jobs run in parallel unless needs declares a dependency, which also forms the graph GitHub uses to order them.
Most workflow failures come from a handful of mistakes: a step with neither run nor uses, a needs pointing at a job that does not exist, indentation that nests a key under the wrong parent, or with placed on a run step. Security issues are subtler — an action referenced by a mutable tag like @v4 instead of a commit SHA can change under you, and a token with broad write permissions is risky on workflows triggered by forks. This validator checks the structural rules GitHub enforces and surfaces the security patterns its documentation warns about.
Common use cases
- Pre-commit checks. Catch a broken workflow before it fails on the first push.
- Reviewing pull requests. Paste a colleague's workflow change for a quick structural sanity check.
- Hardening security. Surface unpinned actions and over-broad token permissions.
- Learning the schema. See exactly which keys a job and a step require.