GitHub Actions Validator
Validate, format and summarize GitHub Actions workflow YAML files against official schemas.
Free online GitHub Actions workflow validator, linter, and formatter. Validate CI/CD workflows, composite actions, and reusable workflows against official GitHub Actions JSON Schemas directly in your browser. Detect YAML syntax errors, missing runner requirements, cyclic job dependencies, invalid action version tags, deprecated commands like ::set-output, unpinned actions, and exposed environment secrets. Generate visual workflow step summaries, normalize indentation (2, 4, or 8 spaces), and convert workflows between YAML and JSON with zero server latency and 100% client-side privacy.
Keywords: github actions validator, gha linter, workflow validator, yaml linter github, github actions schema, composite action validator, validate gha yaml, github actions yaml checker, github workflow linter, action.yml validator, ci cd yaml validator, github actions syntax checker, yaml workflow validator online, github actions linter online, reusable workflow validator, github actions syntax validator, action yaml validator
Tags: github, actions, yaml, ci-cd, validate, workflow, devops
Popular Web Code tools
- Accessibility CheckerScan HTML for WCAG accessibility issues with AI-powered fix suggestions.
- Bundle Size AnalyzerAnalyze and visualize JavaScript bundle sizes with optimization suggestions.
- URL Encoder/DecoderEncode, decode, and parse URLs and query strings instantly.
- SQL FormatterFormat, minify, and validate SQL queries with dialect support.
- SVG OptimizerOptimize, minify, and clean SVG files with configurable SVGO presets.
GitHub Actions Validator is also known as: GitHub Actions Linter, GHA YAML Checker, Workflow Validator Online, GitHub Workflow Syntax Checker, GitHub Actions Schema Validator, Action YAML Validator, Composite Action Linter.
How to GitHub Actions Validator Online
Paste or upload your GitHub Actions workflow YAML (.github/workflows/*.yml) or custom action definition (action.yml / action.yaml) into the editor.
Select an operation mode from the top toolbar: Validate (⌘⇧V) to check compliance against official schemas, Format (⌘⇧F) to clean up indentation, or Summary (⌘⇧S) to inspect jobs and steps.
Configure your preferred indentation width (2, 4, or 8 spaces) and target output format (YAML or JSON) in the formatting options panel.
Review the interactive Issues panel highlighting schema errors, warnings, and exact line and column numbers (such as invalid action refs, missing runs-on, cyclic needs dependencies, or unpinned versions).
Click on any detected issue to jump directly to the target line in your YAML file and apply recommended fixes.
Copy the validated and formatted workflow to your clipboard (⌘⇧C) or share it with teammates via compressed URL parameters.
GitHub Actions Validator Features
Official GitHub Actions JSON Schema Engine: Validates workflow and action manifests against the latest SchemaStore JSON schemas maintained for GitHub Actions.
Heuristic Workflow Type Detection: Automatically recognizes standard CI/CD Workflows, Composite Actions (runs.using: composite), and Reusable Workflows (on: workflow_call).
Cyclic Dependency & Directed Graph Auditing: Detects circular job dependencies within needs arrays before triggering stuck or unexecutable GitHub runner pipelines.
Outdated Action Version Alerts: Identifies legacy action tags (such as actions/checkout@v2 or actions/setup-node@v3) and recommends modern stable releases (v4/v5).
Deprecated Workflow Command Auditing: Flags obsolete ::set-output, ::set-env, and ::save-state syntax, guiding migration to $GITHUB_OUTPUT, $GITHUB_ENV, and $GITHUB_STATE.
Shell Script & Composite Action Validation: Enforces mandatory shell declarations (shell: bash) on all composite action run steps to avoid execution errors.
Hardcoded Secret & Credential Detection: Scans step env mappings for exposed API keys, tokens, and passwords, prompting migration to the repository secrets context.
Line-Level Error & Column Highlighting: Maps JSON Schema validation failures and YAML syntax errors directly back to exact line and column positions.
Bidirectional YAML & JSON Conversion: Converts complex multi-job GitHub Actions workflows into formatted JSON for programmatic AST analysis or pipeline tooling.
Interactive Workflow Structure Summarizer: Generates a high-level overview of workflow triggers (push, pull_request, schedule), job matrices, runners, and execution steps.
Configurable Indentation Formatting: Normalizes nested YAML structures with 2-space, 4-space, or 8-space indentation while preserving multiline scalar formatting.
Job Timeout & Reliability Checks: Flags long-running jobs lacking explicit timeout-minutes settings to prevent runaway runner costs on stuck tasks.
Permissions & Least-Privilege Scoping: Encourages explicit workflow permissions configuration (permissions: contents: read) over default broad privileges.
High-Velocity Keyboard Shortcuts: Accelerate CI pipeline authoring with ⌘↵ (Run), ⌘⇧V (Validate), ⌘⇧F (Format), ⌘⇧S (Summary), and ⌘⇧C (Copy).
Zero-Telemetry Confidential Privacy: 100% client-side WebAssembly and JavaScript execution ensures that proprietary CI configurations and secrets never leave your browser.
CI/CD Ecosystem Compatibility: Seamlessly integrates with DevFlow YAML Converter, Cron Parser, Dockerfile Linter, and Git Conflict Resolver.
Supported Formats & Dialects
The GitHub Actions Validator supports 6 syntax formats and dialects for accurate parsing and processing.
- GitHub Actions Workflow (.github/workflows/*.yml)
- Standard root-level workflow definitions triggered by repository events (push, pull_request, schedule, workflow_dispatch) containing jobs, matrix configurations, and runner environments.
- Composite Actions (action.yml / action.yaml)
- Custom reusable action definitions utilizing runs.using: "composite" with declared inputs, outputs, and shell-scoped execution steps.
- Reusable Workflows (on: workflow_call)
- Modular, centrally maintained workflows invoked across repositories via jobs.<job_id>.uses with typed input parameters, caller secrets inheritance, and outputs.
- Matrix Strategies & Combinatorial Builds
- Multi-platform test configurations running jobs across multiple operating systems, language versions, and compiler toolchains using matrix.include, matrix.exclude, and fail-fast.
- Docker Container Actions & Service Containers
- Containerized workflow execution environments specifying Docker images, entrypoints, and companion background services (e.g., PostgreSQL, Redis) with port bindings and health checks.
- GitHub Context Expressions & OIDC Authentication
- Dynamic expressions (${{ ... }}), runner context variables, secret references, and OpenID Connect (OIDC) token permissions (id-token: write) for cloud provider authentication.
In-Depth Technical Guides
All GuidesDockerfile Best Practices: Layer Caching, Multi-Stage Builds & Security Hardening
A comprehensive developer guide to writing production-grade Dockerfiles: mastering BuildKit cache invalidation, multi-stage builds, non-root execution, and security linting.
GitHub Actions YAML Workflow Debugging: The Top 10 Syntax & Runtime Pitfalls
A comprehensive developer guide to identifying and fixing GitHub Actions YAML syntax errors, matrix build bugs, expression interpolation traps, and concurrency race conditions.
Kubernetes YAML Validation: The 10 Most Common Manifest Mistakes
Diagnose and fix syntax errors, missing resource limits, selector mismatches, and schema validation failures in Kubernetes manifests before deployment.
Mastering Cron Expressions: Syntax, Timezones, and DST Gotchas
Master 5-field and 6-field cron syntax, prevent double executions during Daylight Saving Time (DST), handle UTC schedules, and debug missed server jobs.
Mastering Git Merge Conflict Resolution: 3-Way Diff, Diff3 Markers & Rebase Workflows
Resolve Git merge and rebase conflicts with confidence. Master standard vs diff3 conflict markers, 3-way merge logic, and conflict prevention strategies.
Related Standards & RFC Specifications
All StandardsCron is a time-based job scheduler in Unix-like operating systems configured via cron expressions specifying minute, hour, day, month, and weekday.
A Dockerfile is a declarative text document containing sequential instructions used by the Docker daemon or BuildKit engine to automate container image builds.
GitHub Actions is a declarative continuous integration and continuous delivery (CI/CD) platform integrated into GitHub that enables automated testing, building, linting, and deployment via YAML workflows.
An SBOM is a formal, machine-readable inventory of software components, dependencies, libraries, and licenses that comprise a software build.
Semantic Versioning is a universal three-component versioning specification (MAJOR.MINOR.PATCH) that communicates breaking API changes and compatibility.
YAML is a human-readable data serialization language commonly used for configuration files, Kubernetes manifests, and CI/CD pipelines.
Pre-built Automation Pipelines
Chain GitHub Actions Validator with other utilities in a multi-step visual workflow.
Base64 Decode → JSON Format
Decode a Base64 string and pretty-print the JSON inside it.
CSV → JSON → YAML
Convert CSV data to JSON, then to YAML format.
JSON Format → TypeScript Schema
Format JSON and generate TypeScript/Zod schema from it.
Example Input & Output
Sample ReferenceInteractive Example: GitHub Actions Validator in ActionShow example
Sample Input (text)
name: CI Pipeline
on:
push:
branches: [ main, develop ]
pull_request:
branches: [ main ]
permissions:
contents: read
concurrency:
group: ${{ github.workflow }}-${{ github.ref }}
cancel-in-progress: true
jobs:
test:
runs-on: ${{ matrix.os }}
strategy:
fail-fast: false
matrix:
os: [ubuntu-latest, macos-latest]
node-version: ['20', '22']
timeout-minutes: 15
steps:
- name: Checkout Repository
uses: actions/checkout@v4
- name: Setup Node.js ${{ matrix.node-version }}
uses: actions/setup-node@v4
with:
node-version: ${{ matrix.node-version }}
cache: 'npm'
- name: Install Dependencies
run: npm ci
- name: Run Linter & Tests
run: |
npm run lint
npm testSample Output
[Processed output for GitHub Actions Validator]
Input transformed successfully using github actions validator, gha linter, workflow validator.What happened:
Validate, format and summarize GitHub Actions workflow YAML files against official schemas.
Frequently Asked Questions
- What does the GitHub Actions Validator check and how does schema validation work?
- The GitHub Actions Validator evaluates your workflow YAML files against the official GitHub Actions JSON Schemas (sourced from SchemaStore) using AJV (Another JSON Schema Validator) combined with custom semantic linter rules. It validates required top-level keys (such as "on" and "jobs"), job configurations ("runs-on", "steps", "needs"), step structures ("uses" vs "run"), and YAML syntax. In addition, it performs deep semantic checks for cyclic job dependencies, missing "timeout-minutes", outdated action versions, deprecated workflow commands, and unquoted matrix numbers.
- How does the validator distinguish between standard Workflows, Composite Actions, and Reusable Workflows?
- The tool uses an intelligent structural heuristic: (1) If the YAML contains a root-level "runs" object with a "using" property (e.g., using: "composite"), it is parsed as a Composite Action (action.yml) and validated against the GitHub Action schema; (2) If the "on" trigger defines "workflow_call", it is recognized as a Reusable Workflow, verifying caller inputs and secrets; (3) If the YAML contains "on" and "jobs", it is treated as a standard GitHub Actions Workflow. If neither is present, the parser reports a structural schema mismatch.
- Why should workflows replace deprecated ::set-output and ::set-env commands with $GITHUB_OUTPUT and $GITHUB_ENV?
- GitHub deprecated the legacy runner commands "::set-output" and "::set-env" due to severe security vulnerabilities where untrusted inputs (such as issue comments or pull request titles) could inject malicious runner commands into stdout. Modern GitHub runners enforce file-based environment passing: write outputs using `echo "name=value" >> $GITHUB_OUTPUT` and environment variables using `echo "VAR_NAME=value" >> $GITHUB_ENV`. Our validator automatically scans your run steps and flags deprecated syntax.
- How should expression syntax ${{ }} be used in if: conditions versus run: steps?
- In GitHub Actions, the `if:` conditional automatically evaluates its content as an expression. Wrapping conditions in `${{ ... }}` is unidiomatic and can cause parsing bugs when combining boolean operators (e.g., use `if: github.event_name == 'push' && success()` rather than `if: ${{ ... }}`). Conversely, inside `run:` shell scripts or action `with:` parameters, `${{ ... }}` expression delimiters are strictly required for the runner to interpolate context values before invoking the shell.
- How does the validator detect cyclic dependencies in job needs declarations?
- When multiple jobs specify dependency relationships via `needs: [jobA, jobB]`, the validator builds a Directed Acyclic Graph (DAG) of the workflow pipeline and executes depth-first cycle detection. If Job A needs Job B and Job B needs Job A (or through an extended chain of dependencies), the validator flags the exact cycle with line-level error highlights, preventing stuck queues where runners wait indefinitely for prerequisites that can never start.
- Why is referencing branch names like @main or @master in uses steps dangerous, and what are best practices?
- Referencing a mutable branch tag like `uses: actions/checkout@main` introduces severe supply chain security risks: if the upstream repository updates or is compromised, malicious code or breaking changes will execute in your CI/CD pipeline immediately without review. Best practice is to pin actions to an immutable full commit SHA (e.g., `uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4.1.1`) or a verified major release tag (`@v4`).
- How do you prevent script injection vulnerabilities from untrusted GitHub context variables?
- Directly interpolating user-controlled context values into shell scripts (e.g., `run: echo "PR title: ${{ github.event.pull_request.title }}"`) allows attackers to execute arbitrary shell commands by crafting pull request titles containing quotes and subshells (e.g., `Test"; rm -rf *; echo "`). To prevent script injection, always pass context values into intermediate environment variables: `env: PR_TITLE: ${{ github.event.pull_request.title }}` and reference them securely as `$PR_TITLE` inside your script.
- How does GITHUB_TOKEN permissions scoping work and why should you avoid write-all?
- By default, GitHub repositories may grant broad read-and-write access to the automatic `GITHUB_TOKEN`. To adhere to the principle of least privilege, workflows should declare an explicit top-level `permissions` block (e.g., `permissions: { contents: read }`) and grant specific write permissions only to jobs that require them (such as `packages: write` for container publishing or `pull-requests: write` for automated PR comments). Avoid using `permissions: write-all` to protect against token compromise.
- How do you prevent matrix build combinatorial explosions using include, exclude, and max-parallel?
- When configuring multi-dimensional build matrices (e.g., 3 OS targets × 4 Node versions × 3 database engines = 36 concurrent jobs), unconstrained matrices can quickly exhaust repository runner limits and increase cloud compute costs. You can control matrix breadth by using `matrix.exclude` to eliminate redundant combinations, `matrix.include` to add specific standalone configurations, and `max-parallel: 4` to limit simultaneous runner allocation.
- How does concurrency with cancel-in-progress prevent redundant CI runs and deployment race conditions?
- When developers push frequent commits to a pull request branch, multiple CI runs queue simultaneously. Configuring `concurrency: group: ${{ github.workflow }}-${{ github.ref }}, cancel-in-progress: true` automatically cancels older in-flight runs when a new commit is pushed. For production deployment workflows, omit `cancel-in-progress` (or set it to `false`) to ensure deployments execute sequentially without abrupt mid-step termination.
- Does the GitHub Actions Validator support converting workflow YAML into JSON format?
- Yes. The validator includes bidirectional YAML and JSON parsing. By selecting "JSON" as your output format and clicking "Format" (⌘⇧F), you can convert your entire GitHub Actions workflow into a structured JSON representation. This is especially useful for custom linting scripts, AST inspection, pipeline metrics collection, and infrastructure-as-code automation.
- Is workflow validation performed locally in the browser with zero telemetry privacy?
- Yes. DevFlow executes 100% of the YAML parsing, AST generation, schema evaluation, and semantic linting locally inside your browser using client-side JavaScript and WebAssembly. Your proprietary workflow architecture, internal deployment targets, environment variables, and secret names are never transmitted to any external server or stored in any database.
Related Developer Tools
- YAML ConverterConvert between JSON and YAML with validation, formatting, and multi-document support.
- Cron ParserParse, validate, explain, and build cron expressions with next run times and visual timeline.
- Git Conflict ResolverVisually resolve Git merge conflicts by picking current, incoming, or both versions.
- Dockerfile LinterLint, validate, format, and optimize Dockerfiles with Hadolint-compatible rules, security checks, and multi-stage analysis.
- Env File Parser & ConverterParse, validate, and convert .env files between JSON, YAML, Docker, and Kubernetes formats.
- Text Diff CheckerCompare two text blocks and highlight exactly what changed.
- Kubernetes YAML ValidatorValidate, lint, and format Kubernetes manifests against structure rules, deprecated APIs, and security best practices.
- Prompt Injection & Secret ScannerScan prompts, code, and text for prompt injection patterns, secret leaks, unsafe instructions, and PII exposure.