Document Windows PowerShell encoding caveat when redirecting JSON output

[chiyi-creator]

Summary

While using Grype with Syft-generated SBOMs on Windows, I found that redirecting JSON output with Windows PowerShell > may create a UTF-16LE encoded file. This can break downstream JSON parsers such as Python's json.load(..., encoding="utf-8").

This does not appear to be a Grype bug. It is caused by Windows PowerShell output redirection behavior. However, a short documentation note could help Windows users avoid confusing parser errors when they consume Grype JSON output in automated SBOM/SCA workflows.

Environment

• OS: Windows

• Shell: Windows PowerShell

• Grype version: 0.114.0

• Syft version: 1.45.1

• Python version: 3.12.6

• Platform: windows/amd64

• Workflow:

  1. Generate SBOM with Syft
  2. Scan the SBOM with Grype
  3. Save Grype JSON output to a file
  4. Parse the JSON file with Python

Grype version output:

Application:         grype
Version:             0.114.0
BuildDate:           2026-06-05T16:10:04Z
GitCommit:           ef8e65adb2dec760f1f923e635da4c7696d3c295
GitDescription:      v0.114.0
Platform:            windows/amd64
GoVersion:           go1.26.3
Compiler:            gc
Syft Version:        v1.45.1
Supported DB Schema: 6

Syft version output:

Application:    syft
Version:        1.45.1
BuildDate:      2026-06-05T14:21:36Z
GitCommit:      d4496b05aab2d489a5c2ec606755b657229b8925
GitDescription: v1.45.1
Platform:       windows/amd64
GoVersion:      go1.26.3
Compiler:       gc
SchemaVersion:  16.1.3

Commands to reproduce

cd F:\Github\supply-chain-sca-lab

grype sbom:results\sbom\express.syft.json -o json > results\grype_encoding_repro\express.redirect.grype.json

python -c "import json; json.load(open(r'results\grype_encoding_repro\express.redirect.grype.json', encoding='utf-8'))"

Actual behavior

Python fails to parse the redirected JSON file as UTF-8:

UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte

Inspecting the first bytes of the redirected file shows that it starts with FF FE, which indicates UTF-16LE with BOM:

[System.IO.File]::ReadAllBytes("F:\Github\supply-chain-sca-lab\results\grype_encoding_repro\express.redirect.grype.json")[0..7] | ForEach-Object { $_.ToString("X2") }

Output:

FF
FE
7B
00
22
00
6D
00

Workaround

Using Grype's --file option avoids the PowerShell redirection encoding issue:

grype sbom:results\sbom\express.syft.json -o json --file results\grype_encoding_repro\express.file.grype.json

The resulting JSON file can be parsed by Python with UTF-8:

python -c "import json; json.load(open(r'results\grype_encoding_repro\express.file.grype.json', encoding='utf-8')); print('OK')"

Output:

OK

The file generated with --file starts directly with JSON content instead of FF FE:

[System.IO.File]::ReadAllBytes("F:\Github\supply-chain-sca-lab\results\grype_encoding_repro\express.file.grype.json")[0..7] | ForEach-Object { $_.ToString("X2") }

Output:

7B
22
6D
61
74
63
68
65

Suggested documentation improvement

Add a short Windows PowerShell note near the JSON output or SBOM scanning examples:

On Windows PowerShell, redirecting JSON output with > may produce a UTF-16LE encoded file. If the JSON report will be consumed by Python, jq, CI tooling, or other UTF-8-based tools, prefer Grype's --file option or explicitly write UTF-8 output in PowerShell.

For example:

grype sbom:./sbom.json -o json --file ./grype-report.json

Additional note

During the local test, Grype also printed:

ERROR failed to fetch latest version: Get "https://toolbox-data.anchore.io/..."

This appears to be unrelated to the JSON encoding issue. The vulnerability scan completed successfully, the JSON report was generated, and Python was able to parse the file produced with --file.

Why this matters

Grype is often used in automated SBOM/SCA workflows where JSON output is consumed by scripts or CI tools. A small Windows PowerShell note could help users avoid confusing parser errors and make the Syft → Grype → Python/Excel workflow smoother for beginners.

[kzantow]

There is a PR for this. I can understand the desire to handle this but it seems like a fundamental Windows tooling bug (which they have since fixed/changed); I'm a little torn the right behavior, but I guess it seems like there shouldn't be much harm to check for these UTF BOM markers.