How to Extract Key-Value Data from Forms and Screenshots into JSON

Key-value extraction is a layout interpretation problem

A simple form may look like a list of labels and answers, but real documents introduce columns, section headings, checkboxes, repeated rows, footnotes and empty fields. OCR identifies characters; structured extraction has to decide which value belongs to which label. LoveOCR’s JSON workflow is designed to turn such visual key-value information into structured output, which can be far more useful than copying the text into a document.

The review process should therefore focus on relationships. If “Status” is paired with “Active” in the image but the JSON assigns “Active” to “Type,” both words were recognized correctly while the data is still wrong.

Use section boundaries to prevent label collisions

Many forms reuse labels. “Name” might appear under applicant, emergency contact, and approver sections. A flat object with only one name key cannot represent all three without losing context. Preserve section meaning by nesting objects or by using clearly qualified keys such as applicant_name and approver_name.

When reviewing generated data, search for repeated labels in the image. They are a warning that flattening may create overwrites or ambiguous fields. The most readable visual form is not always the best data model, so structure may need cleanup after extraction.

Distinguish labels from values with typography and position

Bold text is often a label, but not always. A highlighted status value can also be bold. A colon is a useful clue but may be missing. Position is often stronger: repeated left-column text with varying right-column values suggests a label-value pattern. Cards may place a heading above several attributes. Tables rely on column headers instead of per-cell labels.

When one region is ambiguous, compare it with neighboring patterns. Consistency across the page often reveals the intended relationship better than analyzing a single word in isolation.

Checkboxes and selected states need semantic review

A form may encode data through marks rather than words. A checked box next to “Email” and an unchecked box next to “SMS” might logically become preferences.email = true and preferences.sms = false. But a faint tick, filled square, or scan artifact can be misread. Treat selected states as high-risk fields when they trigger permissions, eligibility, consent, or workflow routing.

If the source has an empty box, decide whether the JSON should explicitly store false, store null, or omit the field. That decision belongs to your schema, not to OCR alone.

Missing is not the same as blank

A blank answer can mean the user intentionally left the field empty. A cropped answer may be missing from the image. A blurred value may be present but unreadable. A not-applicable field may be intentionally crossed out. Converting all four cases to an empty string makes later analysis misleading.

For important workflows, define a representation for uncertain extraction. You might keep a separate review flag or record the raw OCR text alongside the normalized value. The exact strategy depends on the application, but uncertainty should be visible rather than silently erased.

Example of grouped form data

{
  "applicant": {
    "name": "Amina Khan",
    "reference_id": "00427"
  },
  "contact_preferences": {
    "email": true,
    "sms": false
  },
  "approver": {
    "name": "R. Malik",
    "date": "2026-08-29"
  }
}

The grouping prevents repeated “name” labels from colliding and preserves the leading zeros of the reference identifier. Your actual schema may be flatter or more deeply nested; the goal is to represent the meaning of the source rather than copy its visual layout literally.

Form-to-JSON review workflow

Related LoveOCR resources

• Image to JSON
• Convert Form to Fillable PDF
• Image to CSV
• Image to JSON structured-data guide

Final review gate before downstream use

Before connecting the output to an API or database, parse it with a real JSON parser and inspect the resulting types. Check whether IDs stayed strings, arrays contain the expected number of items, and optional fields were represented consistently rather than guessed from blank visual areas.

Use a small source-to-field mapping for repeated jobs. It makes later changes easier to review and gives you a clear answer when a value is valid JSON but appears under the wrong key.

Use the purpose of this specific workflow—how to extract key-value data from forms and screenshots into json—to decide how much review is appropriate. A casual personal conversion and an automated production import do not carry the same consequences.

When a value is uncertain, mark it for review instead of silently inventing a correction. Preserving uncertainty is safer than replacing it with a confident-looking but unsupported value.

Privacy and responsible document handling

Structured exports can contain more sensitive information than an ordinary screenshot because the result is easy to search, copy, import, or process automatically. LoveOCR states on its site that uploaded and generated files are processed on its own infrastructure, are not used to train its models, and are automatically deleted after three hours. Those safeguards do not replace your own access controls: only process material you are authorized to handle, keep downloaded outputs in an appropriate location, and remove temporary local copies when the task is finished.

For records with financial values, identifiers, personal details, database commands, or configuration settings, treat OCR as a transcription aid rather than an unquestionable source. Compare high-impact fields with the image before publishing, importing, executing, or sharing the result.

Frequently asked questions