Why:

Related to #43008.

The number-literal row says "Any number format supported by JSON", but the same page demonstrates hexadecimal (0xff), which JSON does not accept. Workflow authors and expression-tool implementers need an accurate description of the accepted syntax.

What's being changed:

Describe decimal integer and floating-point literals, exponent notation and hexadecimal literals explicitly, consistent with the examples already on the page.

Measurements and reproduction

On 14 September 2026, I reran the 44-expression corpus against GitHub Actions: 30 expressions were accepted and evaluated, and 14 were rejected by the expression parser with HTTP 422. The exact workflows, dispatch requests and responses, and successful-run logs are preserved.

The reference snapshot is tagged github-actions-expressions-of-concern. It contains:

• All recorded expressions and results, with a section for each case.
• Structured results.
• Exact workflows, responses, logs and captured source, with an internal SHA-256 manifest and an archive checksum.
• Reproduction instructions and the probe implementation.

For example, the measured 0x1F and 0o17 expressions both evaluate successfully, producing 31 and 15. Their uppercase-prefix counterparts, 0X1F and 0O17, are rejected. The complete table below lets reviewers inspect the accepted and rejected spellings together.

Service-side values were captured in run-name; runner-side values were captured through step environment variables. Both record the text returned by toJSON(). The capture used hosted Ubuntu runners with runner version 2.337.0. For -0, the service recorded 0 and the runner recorded -0; the other 29 accepted results agree.

Validation

• Reproduced all 44 expressions with retained evidence for every verdict.
• The documentation patch changes the number table cell.
• GitHub CI passed, including the documentation build, content lint, rendering and accessibility checks.

Check off the following:

• A subject matter expert (SME) has reviewed the technical accuracy of the content in this PR. In most cases, the author can be the SME. Open source contributions may require an SME review from GitHub staff.
• The changes in this PR meet the docs fundamentals that are required for all content.
• All CI checks are passing and the changes look good in the review environment.