Test Data

Last updated March 23, 2026

Test data lets you preview how your template renders with real values before generating any documents. You enter sample JSON in the payload editor, and the builder immediately reflects that data in the canvas — text blocks show your content, images load from your URLs, and loops repeat over your arrays.

Opening the payload editor

Click the Edit Test Data button in the toolbar at the top of the canvas. This opens a modal containing a full JSON editor powered by Monaco (the same editor used in VS Code).

JSON format

Enter your test data as a JSON object. The top-level keys become the variables available throughout your template. See naming rules for which key formats are valid.

{
  "name": "Jane Smith",
  "company": "Acme Corp",
  "date": "2025-03-15",
  "items": [
    { "description": "Widget A", "quantity": 2, "price": 19.99 },
    { "description": "Widget B", "quantity": 1, "price": 49.99 }
  ],
  "logo_url": "https://example.com/logo.png"
}

The payload editor supports JSON comments — both // single-line and /* */ block comments. Comments are stripped during parsing, so they never affect your template. Use them to note which fields are required or what format a value should take:

{
  // Customer details
  "name": "Jane Smith",
  "email": "jane@example.com",

  /* Items array - each item needs description, quantity, and price */
  "items": []
}

Default test data

Templates created from a Master Template come with a default payload containing common fields like name, company, items, date, and url. Replace these with data that matches your actual document payloads — the default values are just a starting point. Templates created from scratch start with an empty payload.

How test data connects to your template

Test data is the bridge between your template design and the dynamic values that will appear in the final PDF. Three builder features read directly from your test data:

Variable browser

When you configure a property binding — for example, setting the source of an Image block — a variable browser dropdown appears. It lists every path available in your test data. If your test data has logo_url at the top level and items[0].description nested in an array, both paths show up as selectable options.

Visibility conditions

The Logic panel’s conditional display setting evaluates JavaScript expressions against your test data. When you enter a condition like items.length > 0, the panel immediately shows whether the element is currently visible or hidden based on the test data values.

Repetition

When you set up repetition on an element and point it at a collection like items, the builder iterates over that array in your test data. The canvas renders one copy of the element for each item, so you can see exactly how your repeated layout looks with real data.

Live preview

Changes to test data update the canvas immediately. Edit a name, add an item to an array, or change a URL, and the template re-renders in real time. This makes the payload editor the primary tool for debugging dynamic content — if something looks wrong, check your test data first.

Connection to document generation

The JSON structure you use as test data is the same structure you pass as the payload when generating documents through the API or the Dashboard. Keeping your test data realistic ensures what you see in the builder is what you get in the final PDF.

Test data is saved with the template. You can close the editor and come back later without losing your sample payload.

Naming your variables

Your payload keys become JavaScript identifiers that you reference in conditions, bindings, and expressions throughout the builder. Not every string that works as a JSON key works as a variable name.

Valid keys

{
  "someVariable": "Some value",
  "some_variable": "Some value",
  "SomeVariable": "Some value",
  "somevariable": "Some value",
  "$someVariable": "Some value",
  "some": { "variable": "Some value" }
}

These keys are all accessible in the builder. Top-level keys show up directly in the variable browser, and nested keys are accessed with dot notation — some.variable reaches into the some object to read its variable property.

Invalid keys

{
  "some.variable": "Some value",       // Dot conflicts with property access
  "some variable": "Some value",       // Spaces break expressions
  "(someVariable)": "Some value",      // Parentheses are operators in JS
  "'someVariable'": "Some value",      // Quotes aren't valid in identifiers
  "{{someVariable}}": "Some value",    // Braces are syntax characters
  "some-variable": "Some value",      // Hyphen is the minus operator in JS
  "2": "Some value",                   // Bare numbers aren't identifiers
  "2words": "Some value"               // Starts with a digit
}

The most common mistake is using dots in key names. A key like "some.variable" looks like it should work, but the builder interprets some.variable as “the variable property of the some object” — it never finds a key literally named some.variable. If you need nesting, use an actual nested object instead:

{
  // Don't do this
  "customer.name": "Jane Smith",

  // Do this instead
  "customer": { "name": "Jane Smith" }
}
These naming rules apply equally to the payload you send through the API when generating documents. If a key is invalid as test data, it won’t work in production either.

Tips for effective test data

  • Cover all branches: If your template has visibility conditions, include test data that triggers both the visible and hidden states. Switch values between test runs to verify both paths.
  • Use realistic array lengths: If your template repeats over a list of items, test with one item, a handful, and enough items to trigger a page break. Edge cases in repetition are easier to catch early.
  • Match your production payload: The closer your test data resembles real API payloads, the fewer surprises you get when generating actual documents.

Frequently asked questions

What is test data in PDFMonkey’s builder?
Test data is sample JSON you enter in the payload editor to preview how your template renders with realistic content. The builder uses it to populate text, images, and loops in real time before you generate actual documents.
What JSON key formats are valid for PDFMonkey test data?
Keys must be valid JavaScript identifiers: camelCase, snake_case, or dollar-prefixed names work. Keys with dots, spaces, hyphens, or starting with a digit are invalid because the builder treats them as JavaScript expressions.
Is test data saved with my PDFMonkey template?
Yes. Test data is saved with the template, so you can close the editor and return later without losing your sample payload.
Does the test data JSON structure match the API payload?
Yes. The JSON structure you use as test data is the same structure you pass as the payload when generating documents through the API, so keeping test data realistic ensures the builder preview matches the final PDF.
Navigation