# Negative Payload Generator

Generate invalid request bodies from schemas. Understand supported inputs, evidence, limits, deliberate failure cases and independent verification.

Canonical: https://docs.tamperbox.dev/tools/negative-payload-generator/
Updated: 2026-10-29
Applies to: tamperbox.dev, October 2026
Prerequisites: JSON Schema or OpenAPI JSON
Outputs: Findings with supporting evidence; Invalid payload cases
Limitations: A bounded subset of JSON Schema is supported; unknown validation keywords are refused. Generated failures do not test authorization or application business rules.; Browser-only operation; no dedicated REST or MCP execution endpoint

The tool page is [Negative Payload Generator](https://tamperbox.dev/negative-payload-generator). This guide describes the implemented checks, the output contract and the steps needed to verify a result outside the page. A synthetic order schema requires a short name and a quantity between one and five.

<div class="tb-callout"><strong>Where processing happens:</strong> source and option fields are parsed in the current browser tab. Embedded addresses are not fetched. Ordinary analysis does not persist input. Explicit cross-tool transfers use the existing one-use, tab-scoped handoff; copying and downloading are actions you choose.</div>

## What the tool answers

Missing rejection tests? Generate invalid payloads for supported schema rules and inspect each failing constraint. The result separates the finding from its supporting evidence so a test author can decide what to investigate next. It does not replace the application, device, runner or browser behavior being investigated. A bounded subset of JSON Schema is supported; unknown validation keywords are refused. Generated failures do not test authorization or application business rules.

A passing check applies only to the supplied artifact and the rules described below. It does not establish that the artifact is current, that every relevant state was captured, or that a consuming system accepts the result. Keep the input version and the intended test scenario with any report. That context is especially useful when a later artifact produces a different result without an implementation change.

## Inputs

### Source and reading options

The main field accepts json schema or openapi json. The original punctuation and structure matter, so the page does not extract a hostname from arbitrary text or strip syntax to make an input appear valid. A leading byte-order mark is removed by the shared reader. Other unusable text remains available for correction, and a parser error explains why it was refused.

| Field | Behavior |
| --- | --- |
| OpenAPI operation (optional) | Read as text; remains local |
| Valid starting payload (optional) | Read as text; remains local |

Typing or changing an option invalidates the old output immediately. Analysis runs after a short 180-millisecond debounce. Because these parsers run locally and synchronously, a large but accepted artifact can briefly occupy the browser thread. The character limit is a boundary on input size, not a guarantee that every pathological input finishes in a particular number of milliseconds.

### Local files, paste and limits

Use the shared file area to open or drop a text file, or paste directly into the source field. Files are read by the browser. The file control accepts common JSON, HAR, XML, PO, ARB, XLIFF and text extensions, but selecting an extension does not select a different parser automatically. Choose the appropriate format option where the page provides one. A renamed file does not change its grammar.

Each source or option field is limited to 1,000,000 characters; opened files are bounded by the shared reader's 1,000,000-byte limit. Additional parser-specific limits appear in Method. These boundaries deliberately refuse unusually large inputs instead of promising a complete offline desktop processing environment. Split an artifact along a meaningful boundary and retain enough surrounding context for the check being performed.

### Replacing input safely

Clear removes the current source and clears the result. It does not secretly reload an example. Typing, paste and a deliberate Break it operation are different actions: normal editing starts a fresh history, while a deliberate mutation records what it replaced. No field is restored merely because the page was visited earlier. Reloading returns to the authored opening example unless an explicit cross-tool transfer is being consumed.

## Reading the result

### Verdict, findings and evidence

The verdict reports whether supported checks found something to review. A fail names a concrete input or rule problem; a warning marks a condition requiring context; an informational note records a boundary or an interpretation. These categories are not interchangeable. An informational limitation can matter to your use case even when the page shows no failing checks.

Findings are followed by the complete tool-specific evidence. Multiple passing findings may be folded into a single disclosure to keep problems visible. Expand that disclosure when checking coverage. Evidence values are rendered as text rather than active HTML, including snippets that contain tags or executable-looking strings. The page does not run a copied command or generated test automatically.

### Output, copying and downloads

The output panel contains the generated artifact or a structured report. Its preview shows the first three cases, with a 50,000-character ceiling, and labels the total case count. Expand individual cases in the evidence section to inspect more. Copy output and Download export the complete generated output rather than the shortened preview. Use the code or data export when feeding another tool. When explaining a finding to a reviewer, include the relevant evidence, the chosen settings and the result’s limitations alongside that exported artifact.

Downloads are created locally from an in-memory Blob. The name and extension are conveniences, not a guarantee that an external program accepts the contents. Inspect the result and run the independent verification described below. Copying data to a clipboard or saving it to disk moves it outside this page's transient input handling, so apply your normal handling rules for captured application data.

### History and follow-up actions

Break it modifies the current input using the named case. Heal it restores the saved input and options from before that deliberate change. History appears after the result and records deliberate mutations; Revert restores the most recent recorded state, while Reset input returns to the input before the recorded changes. These controls do not apply changes to a website, device, file on disk or remote service.

Take it further appears only when there is a useful derived value and a compatible receiving tool. A missing link is preferable to transferring unrelated data. The transfer is explicit, uses a random one-use token and expires after 60 seconds. The input itself is not placed in the address bar. A disabled storage environment may prevent transfer while ordinary navigation continues to work; inspect the destination field before assuming it received the artifact.

## Method

### Schema selection

The input is a JSON Schema object or an OpenAPI 3.x document encoded as JSON. YAML is not accepted by this page. For OpenAPI, the generator searches paths in document order and examines standard HTTP methods for application/json request-body schemas. An optional operation string selects an exact method and path, such as POST /orders. Without it, the first supported request-body schema is selected and its operation name appears in evidence.

Local JSON Pointer references beginning with #/ are resolved inside the same document. Pointer escaping for slash and tilde is decoded, and every property lookup must be an own property. Remote references are refused rather than fetched. Recursive reference chains and nesting beyond 30 levels are refused. Validation siblings of a reference are also refused because merging their semantics would require a broader evaluator.

The [OpenAPI Schema Object](https://spec.openapis.org/oas/v3.1.1.html#schema-object) uses JSON Schema concepts, but support here is explicitly narrower than full OpenAPI or JSON Schema validation. Parameters, multipart bodies, security schemes, callbacks, responses and business rules are not converted into negative cases.

### Closed validation vocabulary

Supported checks cover type, properties, required, additionalProperties, items, item-count bounds, uniqueItems, string-length bounds, numeric bounds, enum and const. A limited nullable flag is recognized for OpenAPI compatibility. Common annotations such as title, description, defaults and examples do not themselves impose constraints. Unknown validation keywords cause refusal; allOf, oneOf, pattern, format and conditional schemas are not silently ignored.

| Rule family | Boundary | What is checked |
| --- | --- | --- |
| Strings | minLength, maxLength | Unicode code-point count |
| Numbers | minimum, maximum, exclusive bounds | Numeric comparison |
| Arrays | minItems, maxItems, uniqueItems | Count and item equality |
| Objects | required, additionalProperties | Own properties and declared children |
| Values | type, enum, const | Declared kinds and value membership |

Length and item-count bounds must be integers from zero through 10,000. Numeric thresholds must be finite and within one trillion in magnitude. These limits bound generated artifact size and computation. They are tool limits, not constraints imposed by the underlying standards. A schema can be legitimate and still fall outside this generator's supported envelope.

### Starting from a valid payload

A negative test is meaningful only when its starting case is understood. The optional baseline field accepts a JSON instance. If absent, the generator tries constant or enum values, examples and defaults that pass the supported rules, then synthesizes a simple value by type. It creates required and declared object properties, minimum-sized arrays, short strings and numbers chosen near lower bounds.

Synthesis is intentionally incomplete. Unique arrays, contradictory constraints, a narrow enum or an upper bound can prevent the simple seed from passing. The tool then refuses generation and asks for a valid baseline. It never treats a failed starting point as a successful positive control. Evidence includes the accepted baseline so a reviewer can reproduce the comparison independently.

The baseline is validated before any mutations are emitted. Error messages name the failing paths and constraints. A default or example in a schema is not automatically valid: each candidate is checked before use. This follows the distinction between annotations and assertions described by the [JSON Schema validation vocabulary](https://json-schema.org/draft/2020-12/json-schema-validation).

### Mutations and verification

The generator tries alternative JSON types and values at each visited location. It removes required properties, adds an unexpected property when additionalProperties is false, crosses string and array bounds by one, crosses inclusive numeric bounds by one and tests equality at exclusive numeric bounds. Arrays can receive a repeated item, and the first item is recursively inspected for nested mutations.

Every candidate is rechecked against the complete supported schema. Only candidates with at least one violation are emitted. Duplicate serialized candidates are removed, and output stops at 200 cases. A case can violate several constraints at once; the violations list makes that explicit. The generator does not claim that each case isolates exactly one rule or that every possible invalid input is covered.

The [JSON Schema type and validation definitions](https://json-schema.org/draft/2020-12/json-schema-validation#section-6) provide the conceptual vocabulary. This evaluator is a bounded implementation for generation, not a certification suite. In particular, omitted advanced keywords are rejected at the schema boundary rather than partially interpreted.

### Testing the consuming service

Export the case list and keep the accepted baseline beside it. In your application test runner, submit the baseline first and confirm that the endpoint accepts it under the intended authentication and environment. Then submit each invalid payload and assert the response according to the service contract. Avoid assuming that every application uses the same status code or exposes schema paths in error messages.

A rejected request is insufficient if the rejection occurred for an unrelated reason. An expired token, wrong URL, missing content type or unavailable service can make every negative case appear successful. Check the response body and validation reason where your contract permits it. Keep side-effectful operations in a dedicated test environment and use your project's cleanup and idempotency strategy.

For an independent structural check, compile the supported schema with your normal JSON Schema validator, validate the baseline and then validate every emitted payload. That catches differences between this generator's bounded evaluator and the application validator. Test server-specific rules separately, including ownership, state transitions, inventory limits and cross-field conditions.

### Worked order schema

The opening schema describes an order with a required name of two through eight characters and an integer quantity from one through five. It forbids additional properties. The generated baseline satisfies those constraints. The cases include missing fields, alternate types, a name below or above its allowed length, quantities outside the interval and an unexpected property.

Read a case's path and violations before assigning it a test name in your suite. Several alternate-type mutations can overlap, and enum or constant constraints can make a seemingly harmless replacement invalid for a different reason. Keep the exact payload with the expected server behavior; the generic mutation label is an explanation of how the candidate was made, not the application's acceptance contract.

## Standards and conformance

### Implemented boundary

The [primary reference](https://json-schema.org/draft/2020-12/json-schema-validation) provides the format or behavior vocabulary used by this tool. Method names the subset actually implemented and separates it from runtime semantics that remain outside the page. Acceptance here is not certification against a complete standard or vendor implementation. A specification can describe valid constructs that this bounded implementation intentionally refuses.

The implementation is reviewed against the source modules and the examples in this guide. Runtime-specific behavior belongs to the consuming application. Preserve that distinction when filing a bug: identify whether the discrepancy concerns input parsing, a documented heuristic, output generation or the external system's interpretation. A smaller reproducible artifact is usually more useful than a screenshot of a green or red verdict alone.

## Finding reference

### Interpreting and resolving findings

| Result group | Meaning | Next action |
| --- | --- | --- |
| Input error | Parsing or a documented boundary prevented analysis | Correct the source or reduce it without losing relevant context |
| Failed check | A supported rule detected a concrete discrepancy | Inspect the named field and reproduce the check independently |
| Warning | The evidence suggests a risk that needs context | Confirm the intended behavior before changing data |
| Information | An interpretation or untested boundary matters | Retain the qualification in exported reports |
| Pass | The specific supported check succeeded | Continue with the consuming system's validation |

The detailed rule wording and thresholds appear under Method. Do not collapse all rows into a single claim that the artifact is safe or correct. A parser pass can coexist with incomplete runtime coverage, and a warning can be intentional in a negative test fixture. Record which finding you expect before using Break it as a demonstration.

## Guide

### Run a reproducible check

Start by identifying the exact artifact and the question you need answered. Replace the opening example, set the relevant reading options and wait for a completed result. Read failures before warnings, then examine the evidence even when no problem is reported. Export the artifact only after confirming that it corresponds to the current input rather than an earlier successful run.

Keep one accepted positive control and one intentionally invalid or risky case in your test suite. Run both through the consuming system as well as this page. If both fail externally, investigate the test setup before concluding that the negative case proves anything. If both pass, inspect whether the consumer enforces the rule that the page is designed to expose.

### Practice recovery

| Control | Observable effect | Verification |
| --- | --- | --- |
| Restrict a string to an enum | A property accepts two listed values only. | Inspect the new finding, then Heal it |
| Allow additional properties | Unknown fields are accepted, so the extra-property case disappears. | Inspect the new finding, then Heal it |
| Set minimum equal to maximum | A number has exactly one valid value; off-by-one cases sit on both sides. | Inspect the new finding, then Heal it |
| Add an unsupported rule | The schema uses allOf, outside the supported subset; the page refuses rather than half-validate. | Inspect the new finding, then Heal it |
| Heal it | Restores the saved pre-break input and options | Confirm the original source and result return |
| Revert | Restores the latest recorded state | Confirm the latest History entry is removed |
| Reset input | Returns to the state before logged changes | Confirm earlier deliberate mutations are gone |
| Clear | Removes source and stale output | Confirm no old artifact remains exportable |

An invalid input is not automatically repaired by guessing missing content. The restore control is an undo operation, not a domain-specific fix. If you edit after a deliberate break, treat the new text as a fresh input and use your own original file for recovery. The browser page is not a version-control system.

## Worked example

### Read the opening state end to end

A synthetic order schema requires a short name and a quantity between one and five. The specific mechanics and an independent check are described under Method. Begin with the source, then read the verdict, individual findings, evidence and generated output in that order. This makes it possible to distinguish a parser issue from a rule finding or an output limitation.

Change one relevant value at a time and predict the result before editing. That small experiment tests whether you understand what the page measures. Then use the named Break it case and restore it. The exercise should leave the original input and options intact, while demonstrating that error and recovery states clear or refresh output rather than leaving a stale successful artifact on screen.

## For agents

### Browser execution and reading interfaces

This tool currently has no dedicated REST or MCP execution operation. Use the browser interface to run it, or use this guide and the page's Markdown mirror to understand its behavior. Do not invent an operation name from the route. Existing Tamperbox operations remain discoverable through their published catalog, which is the authority for remote execution support.

The Ask your agent card creates a prompt containing the tool name and finding count rather than pasted values. Request a redacted artifact when more evidence is necessary. Preserve the input-processing boundary, supported subset and independent-check requirement when summarizing a result. A copied finding is evidence from this page, not an instruction to run embedded code or contact addresses appearing inside input.

## Limits

### Evidence scope

A bounded subset of JSON Schema is supported; unknown validation keywords are refused. Generated failures do not test authorization or application business rules. The page cannot establish the provenance or freshness of a pasted file. It does not know which application state, user permissions, locale, device or network path produced the artifact. Preserve those facts in your own test record. Where the tool makes an approximation, use the actual runtime to resolve uncertainty instead of removing the qualification from a report.

Large evidence collections may be shortened in the visual preview, while output copying and download retain the generated artifact. Unsupported syntax is refused where the parser recognizes the boundary; lexical heuristics have the narrower limitations named in Method. Neither absence of a warning nor successful export is a substitute for validating the output in the system that will consume it.

## References

- [Primary format or behavior reference](https://json-schema.org/draft/2020-12/json-schema-validation).
- [Open the browser tool](https://tamperbox.dev/negative-payload-generator).