Compare GitHub Actions Workflows Online
Paste two GitHub Actions workflow YAML files. See step changes, trigger modifications, and CI/CD pipeline differences.
🔒 100% private — runs entirely in your browseror try sample data
Paste two GitHub Actions workflow YAML files. See step changes, trigger modifications, and CI/CD pipeline differences.
🔒 100% private — runs entirely in your browseror try sample data
GitHub Actions Diff compares two workflow YAML files and shows you exactly which steps, triggers, and configuration changed. Whether you are reviewing a CI/CD pipeline update, comparing workflows across repositories, or tracking how a deployment pipeline evolved over time, this tool gives you a clear, color-coded view of every modification.
GitHub Actions workflows control your entire CI/CD pipeline — from running tests on pull requests to deploying production releases. A small change like bumping an action version from v3 to v4, adding a new trigger, or modifying a job's runs-on value can have significant effects on build times, security, and deployment behavior. Reviewing these changes in raw YAML, especially for complex multi-job workflows, makes it easy to overlook critical modifications.
Paste your workflow YAML files (from .github/workflows/). The comparison runs entirely in your browser — your workflow definitions, secret references, and environment names are never sent to any server. The tool performs line-by-line comparison with word-level highlighting, so you can see exactly which part of a step or trigger configuration changed.
# Before: v3 actions
steps: - uses: actions/checkout@v3 - uses: actions/setup-node@v3 - uses: actions/upload-artifact@v3 # After: v4 actions
steps: - uses: actions/checkout@v4 - uses: actions/setup-node@v4 - uses: actions/upload-artifact@v4 # The diff highlights each version bump.
# v3 to v4 upgrades often include breaking
# changes in inputs and behavior.Action version upgrades should be reviewed carefully. For example, actions/upload-artifact@v4 changed its default behavior for artifact retention and immutability compared to v3.
# Before: build and test only
jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm test # After: adding production deployment
jobs: test: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - run: npm test deploy: needs: test runs-on: ubuntu-latest if: github.ref == 'refs/heads/main' environment: production steps: - run: ./deploy.shThe diff clearly shows the new deploy job with its dependency on test, branch guard, and environment protection rule. These are critical security controls for production deployments.
# Before: only push to main
on: push: branches: [main] pull_request: branches: [main] # After: adding develop branch and manual dispatch
on: push: branches: [main, develop] pull_request: branches: [main] workflow_dispatch: # Diff shows the added develop branch trigger
# and the new workflow_dispatch for manual runs.Trigger changes affect when and how often workflows run. Adding workflow_dispatch enables manual triggering from the GitHub UI, which is useful for debugging and ad-hoc deployments.
Unlike many other formats, YAML uses indentation to define structure. A step indented under the wrong job, or an env block at the wrong nesting level, can completely change workflow behavior. Be cautious with the "Ignore whitespace" option — it may hide critical indentation changes that alter which job or step owns a configuration block.
Best practice is to pin actions to full commit SHAs (e.g., actions/checkout@a5ac7e51b41094c92402da3b24376905380afc29) rather than version tags. When comparing workflows that use different pinning strategies, the diff will show long SHA strings that may be hard to interpret. Check the action's releases page to verify which version a SHA corresponds to.
Workflows that call reusable workflows (uses: ./.github/workflows/shared.yml) or composite actions may have their actual behavior defined elsewhere. A diff of the calling workflow might look minimal, but the referenced workflow or action could have changed significantly. Compare both the caller and the called workflow for complete coverage.
Paste your workflow YAML files into the two panels and click Compare. The tool shows a side-by-side diff with line-by-line comparison and word-level highlighting for changed steps, triggers, actions, and configuration values.
Yes. Copy the workflow YAML from each repository's .github/workflows/ directory and paste them into the panels. The diff shows every difference in triggers, jobs, steps, environment configuration, and action versions.
Yes. YAML uses indentation for structure, so whitespace changes can be semantically meaningful. A step indented under the wrong job changes which job runs it. Be cautious with the "Ignore whitespace" option for YAML-based workflow files.
Yes. Action version bumps like actions/checkout@v3 to actions/checkout@v4 are highlighted as modified lines. The word-level highlighting pinpoints the exact version change within the uses: line.
Yes. This tool runs entirely in your browser using client-side JavaScript. Your workflow files, including secret references like ${{ secrets.DEPLOY_TOKEN }} and environment names, are never sent to any server.
You can paste any text into the panels, so you can compare a GitHub Actions YAML file with a GitLab CI YAML, CircleCI config, or Jenkins pipeline for migration purposes. The tool performs generic line-by-line text comparison.