XLSX to JSON Converter

The product manager has a spreadsheet. There is always a spreadsheet. This one holds next quarter's launch data — forty-two products with names, prices, categories, and a launch date column — and the message underneath reads: can you seed the staging app with this before Monday standup?

You have three traditional options, all charming. Hand-type the data, which is how transcription errors enter systems. Write a one-off script with a spreadsheet library and an hour of environment setup. Or upload the workbook to one of the conversion sites and let an unknown server enjoy your unreleased product roadmap. Since it is Friday at 4:45, none of these is appealing.

This page is the fourth option. Drop the .xlsx in, pick the sheet, decide how headers become keys, and download a JSON array of typed objects — numbers as numbers, dates as ISO strings, empty cells as null. Thirty seconds, no install, and the roadmap never leaves your machine.

It has become one of the quiet workhorses of the developer tool drawer, because the pattern it serves is permanent: spreadsheets are where non-engineers keep structured data, and JSON is where applications want it. Something has to stand between the two. This is that something.

1. 1

   Drop in the workbook

   Any .xlsx or .xlsm file, read locally by the browser. The converter unpacks the Office Open XML package and lists every sheet in the book, including hidden ones, so you can choose the table you actually meant.

2. 2

   Pick the sheet and the header row

   The first row is the header by default, and the dropdown moves it if your sheet carries a title banner above the real headers. Each header cell becomes a key; everything below becomes records.

3. 3

   Choose your key style

   Keep headers exactly as written, or normalize them to snake_case or camelCase. Unit Price becomes unit_price or unitPrice — a small setting that saves a mapping layer in your code.

4. 4

   Pick array mode or keyed mode

   Array mode emits a list of objects. Keyed mode promotes a column you choose to the outer keys, producing a lookup map instead. Pick whichever matches how your code will query the data.

5. 5

   Convert, review, download

   The preview shows the first records with their detected types, and the download button serializes the full set. Pretty-printed output for reading, compact output for pipelines — one toggle.

A worksheet is a grid of cells; a JSON document is a tree of values. The bridge between them is the header row: each column header names a key, and each subsequent row supplies the values for one object. Row 7 of the sheet and element 6 of the array are the same information, readdressed.

The interesting work is typing. Inside the workbook — an Office Open XML package standardized as ECMA-376 — every cell already carries a type: shared-string text, number, boolean, or a date stored as a day-count with a format costume. The converter maps those honestly: strings to strings, numbers to numbers, booleans to true and false, and dates to ISO 8601 strings, because JSON as defined in RFC 8259 has exactly six value types and a date is not among them. The ISO convention — 2026-03-04T09:30:00Z — is the ecosystem's answer, and it sorts correctly as text, which is a property you will come to appreciate.

Empty cells get the same deliberateness: they become null, not an empty string and not a missing key. The distinction matters the moment your code asks is this blank or absent — blank means someone cleared a value, absent means the column never applied. Spreadsheets flatten that difference visually; JSON can preserve it, so it does.

Formula cells export their cached values, exactly as in the XLSX-to-CSV tool: the workbook stores both the formula and the value Excel last computed, and the JSON gets the value. An extended-price column arrives as a number ready to use, not as an arithmetic string your code would have to evaluate.

Array mode is the default because it is the most common need: an array of objects, one per row, ready for a forEach or a bulk insert. When your code iterates — rendering a list, seeding a table, feeding a chart — an array is the right shape and needs no argument.

Keyed mode exists for the other access pattern. Designate an ID column — sku, employee_id, country_code — and the converter emits an object whose keys are that column's values, mapping each to the row's record. Code that looks records up by identifier stops linear-searching and starts addressing directly.

// Array mode (default)
[
  { "sku": "A-1101", "name": "Verona Dark", "price": 42 },
  { "sku": "A-1102", "name": "Harbor Blend", "price": 18.5 }
]

// Keyed mode, keyed on sku
{
  "A-1101": { "name": "Verona Dark", "price": 42 },
  "A-1102": { "name": "Harbor Blend", "price": 18.5 }
}

A rule of thumb that has aged well: if your consumer renders or iterates, take the array; if it fetches-by-identifier, take the map. And if you are not sure, take the array — every language turns a list into a lookup in one line, while the reverse trip is more ceremony than it is worth.

Back to the 4:45 spreadsheet. The sheet is called Launch, the headers are friendly English, and the launch date column is real dates. Here is exactly what the round trip looks like, trimmed to three rows.

Small things worth noticing: Unit Price became unit_price without anyone writing a mapping function; 42.00 serialized as 42 because JSON numbers do not carry trailing zeros; and the launch dates exported as ISO strings that sort chronologically as plain text. None of that required a decision from you — which is the correct amount of decision-making for a Friday afternoon.

Spreadsheet date cells hold a day-count, and cells with times hold a fraction of a day: 09:30 on March 4, 2026 is the single number 46092.3958333 wearing a format. Nowhere in that cell — anywhere in the workbook, in fact — is a time zone. The sheet does not know whether that 09:30 happened in Chicago or Warsaw, and it is not lying to you; it never claimed to know.

This matters because JSON consumers often expect a zone. An ISO string with a Z suffix claims UTC; an ISO string without one claims nothing. The converter deliberately emits the second kind — the date and time exactly as stored, with no zone invented — because inventing one is how 09:00 meetings drift three hours between the seed data and the calendar view. If your application needs UTC, the correct move is to convert deliberately in code, with the business's actual time zone stated in one place, rather than have a converter guess it silently at export time.

Mixed columns are the other recurring headache: a launch-date column that is half real date cells and half text typed by hand exports as half ISO strings and half whatever the author typed — 3/4/26 next to 2026-03-04. The preview shows you this immediately, which is the right moment to see it. The durable fix is one rule, applied at the source: every date column contains real date cells in ISO display format, and nothing else lives there.

The conversions that go badly are almost never conversion problems — they are hygiene problems that conversion exposes. JSON is stricter than a spreadsheet grid: it has types, it has no merged cells, and it will happily represent a mess with perfect fidelity. A five-minute pass over the workbook before converting buys a clean payload for the life of the project. The pass has five moves:

1. Make row one a single flat header — no banners, no merged title cells, no second header row stacked beneath the first
2. Give every column one job and one type — dates are date cells, codes are text cells, numbers are number cells
3. Delete the decorative rows — section separators, blank spacer rows, and the summary block someone appended below the table
4. Format identifier columns as text before entering data — barcodes, ZIP codes, and long digit keys, so they never become floats
5. Rename duplicate headers before converting, since two columns named Notes cannot both become a key

That list reads as tedious and is, in practice, about three minutes of clicking for the average sheet. The reward is a JSON file your code can trust without defensive checks on every field — and if the sheet will be edited again next quarter, as business spreadsheets always are, the hygiene compounds. The alternative is a mapping layer in your application that quietly grows to two hundred lines, one workaround per historical formatting decision.

There is a cultural point here too, learned from watching these hand-offs for years: the spreadsheet's author is usually willing to follow the five rules if anyone asks, and nobody asked. Making the data clean at the source turns a recurring conversion ritual into a two-minute courtesy on both sides.

The header row is where authors express themselves, and expression is the enemy of clean keys. Headers arrive with spaces, slashes, ampersands, trailing spaces, and the occasional emoji. The key-normalization modes absorb most of it, but duplicate headers cannot be absorbed — two columns both named Notes will collide, and the converter flags it rather than silently keeping the last one, because silent key loss is a data-integrity bug wearing a success message.

• Two-row or merged headers — cannot be auto-flattened; flatten them in the workbook first
• Numbers that are secretly labels — barcodes and ZIP codes typed as numbers lose leading zeros at the source, and the converter faithfully reports the damage
• Mixed-type columns — a Notes column that is mostly text with a few stray numbers exports as strings and numbers side by side; clean it or type-guard the consumer
• Trailing empty rows — formatting borders and stray spaces below the table create phantom records with null fields; the converter skips fully-empty rows by default
• Percent cells — store 12.5%, export 0.125; the format was a costume, the number is the value
• Very long digit strings — a 20-digit customer key overflows double precision; such columns should be text in the workbook, or they will round at the fifteenth significant digit

That last item deserves emphasis because it is the least obvious and the most permanent: spreadsheets store numbers as 64-bit binary floats, which hold roughly fifteen significant digits exactly. IDs from systems that generate 18- or 20-digit keys will round, silently, the moment someone types them into a numeric cell. Text-format the column, then convert. The twenty-digit key that survives Excel is the one that never became a number.

And the boundary we always state: this converts sheets to JSON. It does not validate that the JSON matches your application's schema. If launch_date must be a date and category must be one of five values, that validation belongs in your code or in the JSON Formatter & Validator after a paste — conversion moves data; it does not bless it.

Frontend developers seeding apps: mock data, translation tables, menu trees, configuration — anything a stakeholder insists on maintaining in a spreadsheet because spreadsheets are what they trust. The converter turns that trust into structured data without a weekly hand-off ritual.

Backend and data engineers use it for one-off imports and prototype pipelines: a vendor's price sheet becomes a JSON payload for a stub endpoint, a survey export becomes fixtures for tests. Low-code and automation builders feed JSON into platforms whose blocks expect objects, and the spreadsheet is upstream of nearly every business process they automate.

• Seeding databases and staging environments from business-owned spreadsheets
• Generating mock data and fixtures with realistic values instead of lorem numbers
• Turning translation sheets into locale files before an international release
• Bridging no-code platforms that speak JSON but not XLSX
• Reviewing a workbook's real contents as data rather than as a formatted grid

Teachers use it to hand students datasets in a format their JavaScript course can consume immediately, and analysts use it to hand engineers data in a format that does not start a conversation about delimiters. Both are the same transaction: someone meeting the machines halfway.

The common alternative is a two-step: export the sheet to CSV, then run a CSV-to-JSON converter. It works, and for plain tables it works identically. The differences appear at the edges, and they all favor reading the workbook directly.

The CSV route also requires Excel to be installed and willing — each sheet must be exported by hand, which quietly caps how often anyone will do it. The direct route has no such dependency; the person with the workbook does not need to be the person doing the conversion. For recurring hand-offs, that difference compounds.

For completeness: when JSON is the input instead, the sibling tools run the other direction — the CSV to JSON Converter for text tables, and Nested JSON to CSV when someone's nested payload needs to become a grid an executive can open. The whole family shares the runs-in-your-browser rule, so choosing between them is a question of shape, not of trust.

Spreadsheets that become JSON are usually doing something delicate: seeding unreleased features, carrying employee data, feeding internal dashboards. The interesting question for any converter is not whether it promises privacy but whether it could violate privacy if it wanted to. This one could not — the tool has no upload path in its code. The workbook is read into the page, parsed there, serialized there, and the download is generated there.

The verification ritual, if you like verifying: open the browser's developer tools, clear the Network panel, and drop in a workbook. Watch for a request that carries your data — there is none to watch for. Then disconnect from the internet and convert another sheet, because a tool that works offline cannot be phoning your roadmap anywhere.

No account to create, no file kept, no most-recent list to clear. Close the tab and the sheet is gone from memory. The only artifact of the whole transaction is the JSON file you chose to download — which is exactly the artifact you wanted.

Most sheets that become JSON also need to become plain text at some point — the XLSX to CSV Converter is the same read engine pointed at flat output, with a sheet picker and a UTF-8 BOM option. And when the data's next stop is a consumer that thinks in records rather than cells, CSV to JSON covers the text-format lane.

For the trip in reverse — nested payloads that need to become somebody's spreadsheet — Nested JSON to CSV flattens object graphs into columns without hand-writing the flattening logic. All three share this page's local-only processing, which is less a feature than a design stance.