Convert GitHub Actions Workflow YAML to JSON

Top-level name, on, and jobs map straight across. Note that on is a quoted string key in the output.

Input (ci.yml):
name: CI
on:
  push:
    branches: [main]
jobs:
  build:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

Output JSON (2-space):
{
  "name": "CI",
  "on": { "push": { "branches": ["main"] } },
  "jobs": { "build": {
    "runs-on": "ubuntu-latest",
    "steps": [ { "uses": "actions/checkout@v4" } ]
  } }
}

The converter never resolves ${{ }}. The literal string survives so you can scan the JSON for every secret a workflow touches.

Input:
jobs:
  deploy:
    steps:
      - run: deploy --token ${{ secrets.DEPLOY_TOKEN }}
        env:
          API_KEY: ${{ secrets.API_KEY }}

Output JSON (expressions literal):
{ "jobs": { "deploy": { "steps": [ {
  "run": "deploy --token ${{ secrets.DEPLOY_TOKEN }}",
  "env": { "API_KEY": "${{ secrets.API_KEY }}" }
} ] } } }

Audit: grep the JSON for `secrets.` → both refs found.

A literal block scalar becomes a JSON string with \n between lines, so a scanner sees the whole script.

Input:
steps:
  - run: |
      npm ci
      npm run build
      npm test

Output JSON:
{ "steps": [ { "run": "npm ci\nnpm run build\nnpm test\n" } ] }

(Each command on its own line, newlines preserved.)

Convert, then run a JSONPath over the result to list dependencies for a pinning audit.

After converting workflow.yml to JSON, in the JSON Path Extractor:
  $.jobs.*.steps[*].uses

Result:
[
  "actions/checkout@v4",
  "actions/setup-node@v4",
  "docker/build-push-action@v5"
]

Folded block scalars behave per spec — newlines become spaces. Use | instead if you need the line breaks kept.

Input:
jobs:
  build:
    name: >
      Build and
      test the app

Output JSON:
{ "jobs": { "build": { "name": "Build and test the app\n" } } }

(The two lines folded into one space-joined string.)

Expressions are preserved as literal strings, never evaluated — there is no GitHub context to evaluate against in a converter. This is the correct behavior for auditing (you can grep for secrets.), but if you wanted the resolved value, that only exists at runtime on GitHub's runners.

Some older YAML 1.1 tools coerce the bare word on to boolean true, mangling the trigger block. js-yaml 4.x uses the YAML 1.2 core schema, so on stays the string key "on" and $.on.push resolves correctly. No quoting needed.

A folded block scalar (>) joins lines with spaces, which breaks a multi-command shell script. Workflows should use the literal block scalar (|) for run: so newlines are kept. If your output script is one space-joined line, the source used > — switch it to |.

YAML forbids tab indentation; a tab throws tab characters must not be used in indentation with line and column. GitHub's own parser would reject the workflow too. Re-indent with spaces.

Two jobs with the same id, or any repeated key in one mapping, throw duplicated mapping key. The parser rejects rather than silently keeping the last one — fix the workflow so ids are unique.

If you pasted several workflows into one file separated by --- and left the multi-doc toggle off, you get expected a single document in the stream, but found more. Turn on Multi-document YAML (---) to get a JSON array of workflows.

Standard workflows have no custom tags, but an accidental !-prefixed tag throws unknown tag. The parser only knows YAML 1.2 standard tags. Remove the tag or quote the value.

An empty file or comments-only file parses to undefined, and the output is the literal undefined rather than {}. Paste the actual workflow content.

Some teams DRY up matrix steps with YAML anchors. The converter resolves them — the JSON has the anchored block expanded inline at every alias site, with no &/* left. The output is functionally identical to GitHub's expansion.