Validate PDF form fields and required values
Before a form is filled, Ada Lovelace's name, a birth date of 1815-12-10 and the email choice are checked against four field rules, and the unanswered newsletter box is listed as optional. A date like 2025-02-29 is refused. Free in your browser.
- Free
- Runs in your browser
- No sign-up
- Your data stays on your device
Run — free
Runs in your browser. Free, unlimited — your data never leaves this page.
Validate the data intended for a PDF form before a document-filling step begins. Supply the form field definitions and a values object, and this capability checks required fields, exact value types, real calendar dates, allowed choices, duplicate definitions, and unexpected keys. It returns a clean set of validated values when everything matches.
Define the form contract clearly
Start by describing each PDF form field with a unique name, a supported type, and an optional required flag. Supported types cover text, finite numbers, integers, booleans, ISO calendar dates, single-choice selects, and multiple-choice selects. Select fields also need an options list so the validator can distinguish an approved choice from an arbitrary string.
The definitions are the contract for the values object: every supplied value must correspond to one definition, and duplicate field names are rejected because they would make validation ambiguous. Use the exact field names expected by the later PDF-filling operation, including capitalization. This capability deliberately does not inspect a PDF or guess its fields.
Keeping field discovery separate from value validation makes each step easier to test and lets the same contract be reused across many records. Required defaults to false when it is omitted, while an explicitly required field must contain a meaningful value. For text fields, whitespace-only content is treated as missing rather than as completed input.
Understand strict value validation
Values are checked without automatic coercion. Dates use the unambiguous YYYY-MM-DD form and must represent a real calendar day, so an entry such as 2025-02-29 is rejected. A select value must exactly match one of its declared strings, including case.
A multiselect value must be an array of unique allowed strings; repeated or unknown choices fail validation. This strict behavior catches mapping mistakes before they become subtly wrong documents. Required fields using those empty representations produce an error that names the missing field.
The first error stops the operation, providing a focused issue that a form or pipeline can present to its user.
Place validation before PDF generation
Use this capability immediately after mapping application data to PDF field names and before calling a tool that writes into the actual document. A successful result includes valid true, the number of field definitions examined, the accepted values, and the optional fields that were not supplied. Unknown keys are rejected because a misspelled field name would otherwise disappear silently during PDF filling.
This makes the validator especially useful in batch workflows, where one bad mapping could affect hundreds of documents. Store the field definitions alongside the template version, validate every record against that version, and send only successful records to the fill stage. The algorithm runs locally without network access, random behavior, model inference, or stored state, so identical inputs always produce identical results.
What you can do with it
Preflight onboarding forms
Check names, dates, consent booleans, and required selections before generating completed employee or customer forms.
Protect batch document jobs
Reject a malformed record before it reaches a PDF-writing queue and creates an incomplete document.
FAQ
Does this capability edit the PDF?
No. It validates field definitions and values only. Pass the validated values to a separate PDF-filling capability.
How are dates validated?
Dates must use YYYY-MM-DD and identify a real calendar day, including correct leap-year behavior.
Can values contain fields not present in the definitions?
No. Unknown keys are rejected to expose misspellings and stale template mappings.
What happens if a required field contains only spaces?
It counts as empty, so the check fails and the message names that field. Only a meaningful value completes a required text field; optional fields left out are simply listed as not supplied.
Will it accept “yes” for a checkbox or a whole number typed as text?
No. Nothing is converted for you: a yes-or-no box needs a true or false value, not the word yes or the digit 1, and a whole number must arrive as a number, not as the text 12.
Related tools
For developers — API access
Everything on this page is available programmatically. This section is for teams who want to wire it into their own systems; everyone else can just use the tool above.
API endpoint
Prefer to automate it? One authenticated POST creates the task; the result comes back by webhook or a signed link. The same capability also runs here on the web, by email and from Telegram — and soon from our app too.
Call it from your stack
curl -X POST https://api.kit.forhosting.com/pdf/fill-form-fields \
-H "Authorization: Bearer $KIT_KEY" \
-H "Content-Type: application/json" \
-d '{"fields":[{"name":"full_name","type":"text","required":true},{"name":"age","type":"integer","required":false}],"values":{"full_name":"Ada Lovelace","age":36}}'const res = await fetch("https://api.kit.forhosting.com/pdf/fill-form-fields", {
method: "POST",
headers: {
"Authorization": `Bearer ${process.env.KIT_KEY}`,
"Content-Type": "application/json"
},
body: JSON.stringify({
"fields": [
{
"name": "full_name",
"type": "text",
"required": true
},
{
"name": "age",
"type": "integer",
"required": false
}
],
"values": {
"full_name": "Ada Lovelace",
"age": 36
}
})
});
const { task_id } = await res.json();import os, requests
res = requests.post(
"https://api.kit.forhosting.com/pdf/fill-form-fields",
headers={"Authorization": f"Bearer {os.environ['KIT_KEY']}"},
json={
"fields": [
{
"name": "full_name",
"type": "text",
"required": true
},
{
"name": "age",
"type": "integer",
"required": false
}
],
"values": {
"full_name": "Ada Lovelace",
"age": 36
}
},
)
task_id = res.json()["task_id"]<?php
$res = file_get_contents("https://api.kit.forhosting.com/pdf/fill-form-fields", false, stream_context_create([
"http" => [
"method" => "POST",
"header" => "Authorization: Bearer " . getenv("KIT_KEY") . "\r\nContent-Type: application/json",
"content" => '{"fields":[{"name":"full_name","type":"text","required":true},{"name":"age","type":"integer","required":false}],"values":{"full_name":"Ada Lovelace","age":36}}',
],
]));
$task = json_decode($res, true);body := bytes.NewBufferString(`{"fields":[{"name":"full_name","type":"text","required":true},{"name":"age","type":"integer","required":false}],"values":{"full_name":"Ada Lovelace","age":36}}`)
req, _ := http.NewRequest("POST", "https://api.kit.forhosting.com/pdf/fill-form-fields", body)
req.Header.Set("Authorization", "Bearer "+os.Getenv("KIT_KEY"))
req.Header.Set("Content-Type", "application/json")
res, _ := http.DefaultClient.Do(req)Example request
{
"fields": [
{
"name": "full_name",
"type": "text",
"required": true
},
{
"name": "age",
"type": "integer",
"required": false
}
],
"values": {
"full_name": "Ada Lovelace",
"age": 36
}
}Example response
{
"task_id": "tsk_a1b2c3d4e5f6a1b2c3d4e5f6",
"type": "pdf.fill_form_fields",
"status": "queued",
"_links": {
"result": "/tasks/tsk_…/result"
}
}The API is asynchronous: the call returns a task_id immediately and the result arrives by webhook. Polling is capped at 1 req/s per task.
Pricing
Published price — no tokens, no invented credits. A failed task is never charged.
Limits
max_mb | 25 |
max_pages | 200 |
Errors
| HTTP | Code | Meaning |
|---|---|---|
401 | unauthorized | Missing or invalid API key. |
402 | insufficient_balance | Your balance doesn't cover the task price. |
404 | unknown_type | That task type doesn't exist. |
429 | rate_limited | Too many requests. Use the webhook instead of polling. |
Technical notes
Because validation is deterministic and does not open or alter a PDF, it is useful both as a browser-side preflight and as a predictable API guard in document automation.
Understand strict value validation
An integer must arrive as a JSON number with no fractional part, not as the string "12". A boolean must be true or false, not "yes", 1, or 0. Number fields accept only finite JSON numbers. Optional fields may be absent, null, or an empty string and are then listed in missing_optional instead of being copied into validated_values.
Place validation before PDF generation
The validated_values object preserves the accepted JSON values exactly; it does not format dates, round numbers, reorder selections, or invent defaults. Browser use is available for interactive checks, while an API request costs $0.002 when validation is part of automated document production.
Integration use cases
Test template mappings
Verify that an application's output keys and JSON types still match the contract for a versioned PDF template.
Technical questions
What happens when a required field is missing?
The request fails with an invalid_input error that names the required field.
Are numeric strings converted to numbers?
No. Validation is strict, so a number or integer must be supplied as a JSON number.
What does an API request cost?
Each request costs $0.002. The deterministic validator can also run in the browser.