Converting a PDF to JSON turns the text printed on a page into named records a program can read: each table row becomes an object with keys such as date, description and amount, and details printed once, like an account number, sit in their own fields. You get structure, not layout. JSON suits scripts and apps; a spreadsheet suits people.
What does a PDF to JSON conversion produce?
A PDF to JSON conversion produces a text file of keys and values. The fonts, positions and page breaks of the PDF are gone. What remains is the content, labelled. A converter reads the page, works out which pieces of text belong together, and writes each piece under a name.
JSON itself is small. The JSON standard, RFC 8259 defines four primitive types (strings, numbers, booleans and null) and two structured types, objects and arrays. Every PDF to JSON file is built from those six. An object is a set of named values in curly braces. An array is an ordered list in square brackets. A table usually becomes an array of objects, one object per row.
That is the main shift from a spreadsheet. In Excel, a value lives in a cell, and its meaning comes from the header at the top of its column. In JSON, every value carries its own name. Move a record to another file and it still says what each field is.
A PDF has no such names. It stores characters and the coordinates where they are drawn. So the converter has to infer them, from column headings, from position, or from knowledge of a document type. That inference is where the quality of a conversion is decided.
Two kinds of PDF input
Text PDFs, the kind a bank or billing system generates, contain real characters, so a converter can read them directly. Scanned PDFs are pictures of pages, and they need text recognition first. If you only need the words in reading order, without keys, converting a PDF to plain text is simpler and loses less.
From PDF table rows to JSON records
A PDF table row becomes a JSON record when the converter assigns each piece of text on that line to a column, then writes the column names as keys. The column headings printed on the page are the usual source of the key names, cleaned up into short lowercase words that a program can type.
Here is a worked example. The values are made up for illustration. A statement page prints this line under the headings Date, Description, Amount and Balance:
09/12 CLIENT PAYMENT INV 1187 1,650.00 7,357.37
Copied as plain text, that is one string with spaces. A converter that understands the columns writes it as a flat record:
{
"date": "2026-09-12",
"description": "CLIENT PAYMENT INV 1187",
"amount": 1650.00,
"balance": 7357.37
}
Four things changed on the way. The date gained a year, taken from the statement period, because the page printed only month and day. The date was rewritten in year-month-day order, which sorts correctly as text. The thousands separators were dropped from the money. And the padding spaces between columns disappeared, because the keys now do the job the spacing did.
Whole tables follow the same pattern. A page with forty transaction lines becomes an array of forty records, in the order they were printed. A program can then loop over the array, total the amounts or filter by description without knowing anything about the original page.
Lines that wrap
Some descriptions run onto a second printed line. A careful converter joins the two lines into one description string. A careless one creates a second record with only a description and no date or amount. Counting records against the printed lines catches this.
Nested JSON fields for headers, pages and line items
Nested JSON fields hold information that applies to a group of rows rather than to one row. A JSON object can contain other objects and arrays, so details printed once, such as the account holder, the statement period and the opening balance, go in a parent object, and the rows go in an array inside it.
A spreadsheet has to repeat those details on every row or leave them out. JSON can say them once:
{
"account": {
"holder": "Juniper Street Studio",
"number_last4": "3017",
"period_start": "2026-09-01",
"period_end": "2026-09-30"
},
"opening_balance": 4210.55,
"transactions": [
{ "date": "2026-09-01", "description": "CLIENT PAYMENT INV 1182", "amount": 2400.00 },
{ "date": "2026-09-03", "description": "CORNER PRINT SHOP", "amount": -86.40 }
]
}
The example names a fictional business. Nesting can go deeper. An invoice can hold an array of line items, each with its own quantity and price. A property report can hold units inside buildings inside a portfolio. A rent roll is a good case: one property header, then one record per unit with tenant, lease dates and rent. If that document needs to end up in a sheet instead, turning a rent roll PDF into Excel covers the column layout.
How deep is too deep?
Each level of nesting is a decision someone reading the file must understand. Two levels, a header object and a row array, cover most documents. Page numbers rarely deserve their own level; store the page as a field on each record if you need it for checking, and keep the rows in one array across pages.
Numbers versus strings in converted JSON
Numbers and strings look alike on a PDF page, but in JSON they are different types. 1650.00 without quotes is a number that a program can add. "1,650.00" in quotes is text, and adding it to another amount either fails or joins the two strings end to end. Which one you get depends on the converter.
A converter has good reasons to keep some numbers as strings. Account numbers, check numbers, sort codes and ZIP codes are digits, not quantities. Written as JSON numbers, they would lose their leading zeros, and long ones could lose digits. RFC 8259 says integers between minus and plus 2 to the power 53, less one, are the range where implementations agree exactly on the value; beyond that, a parser may round. A 19-digit card reference is safely past that line, so it belongs in a string.
Money is the harder case. A JSON number such as -86.40 reads naturally and sums easily, but many languages parse it into a binary floating-point value that cannot hold every decimal exactly. Some systems store cents as whole numbers, others store amounts as strings and parse them with a decimal type. The trade-offs are laid out in storing money amounts in JSON safely.
A quick test tells you what you have. Open the file in a text editor and look at an amount. Quotes around it mean a string. No quotes means a number. Commas or currency symbols inside the value mean the converter copied the printed text without parsing it.
Signs and the minus character
Statements show money going out in several ways: a minus sign, parentheses, a trailing CR or DR, or a separate debit column. In JSON, a debit should arrive as a negative number or in a clearly named debit field. A typographic minus, which looks like a hyphen but is a different character, will stop a number from parsing at all.
When should PDF data go to JSON instead of a spreadsheet?
PDF data should go to JSON when the next reader is a program, and to a spreadsheet when the next reader is a person. JSON wins when you are feeding an app, a database or an API, when records have nested parts, or when the same fields must be read the same way every month without anyone opening the file.
Some concrete cases where JSON is the better target:
- A script that categorises transactions. It reads the array, matches descriptions and writes totals. No one looks at the rows.
- An app import. Many web services accept JSON uploads, and the field names map directly to theirs.
- Documents with groups. Invoices with line items, or statements with several accounts, keep their structure instead of being flattened.
- Repeat conversions. Twelve monthly files with the same keys can be merged by code in seconds.
A spreadsheet is the better target when someone needs to scan, sort, highlight or comment on the rows, or when the file goes to a bookkeeper or an accountant. Excel can open JSON, though: Microsoft's documentation for the Power Query JSON connector says loading a JSON file opens the Power Query editor, which flattens the data into a table automatically.
For bank statements specifically, converting a bank statement to JSON goes through the fields worth keeping and how to check them. FastBankConvert, which is getting ready to open, is built to return a statement as Excel, CSV or JSON from the same upload, so you can choose the format per job; Get started to join the list.
PDF to JSON mistakes that break the script reading the file
PDF to JSON mistakes rarely show up when you look at the file. They show up later, when a script throws an error or, worse, quietly produces the wrong total. Most come from the same handful of causes: wrong types, wrong encoding, repeated keys and lost or duplicated rows.
Run these five checks on any converted file before you build on it:
- Parse it. Load the file with any JSON parser. A trailing comma or an unescaped quote inside a description stops the whole file from loading.
- Count the records. Compare the length of the transaction array with the number of lines printed in the PDF. A wrapped description often adds a phantom record.
- Check the types. Every amount should be the same type in every record. A file where most amounts are numbers but one is
"1,204.50"will break a sum halfway through. - Check the keys. Each record should use the same key names, spelled the same way. RFC 8259 says that when names inside an object are not unique, the behaviour of the software that receives it is unpredictable; some parsers keep the last value and others reject the object.
- Check the encoding. RFC 8259 requires JSON exchanged between systems outside a closed ecosystem to be UTF-8. A description with an accented name that turns into odd symbols points to a file saved in another encoding.
Mixing up dates
A date such as 03/04/2026 means March 4 in the US and 3 April in much of the world. Writing it as 2026-03-04 removes the doubt. If your converter keeps the printed form, convert it yourself once, at the start, rather than in every script that reads the file.
Reconcile before you trust it
For any document with totals, add up the amounts and compare the result with the printed total or the change in balance. A match does not prove every field is right, but a mismatch proves something is wrong, and it is far cheaper to find that before the data is loaded into another system.