A local Excel to JSON converter can turn one GST worksheet from a .xlsx workbook into a structured JSON file of records in under a minute, reading only stored cell values from a 20 MB browser-side export. The conversion is intentionally narrow: one worksheet per export, one header row of unique field names, and one JSON record per data row, with empty cells written as null and text, number, or Boolean values preserved as ordinary JSON values. For GST workbooks built around invoice registers, HSN summaries, or return-ready tables, this is a direct bridge from a familiar spreadsheet format to a payload that an API or a developer tool will actually accept. Because the workbook never leaves the browser tab, confidential GSTIN numbers, taxable values, and party names stay on the same machine where the file was opened. The tool ignores formulas, macros, external links, and embedded scripts on purpose, so the JSON reflects exactly what was last saved into the spreadsheet and nothing the workbook computes behind the scenes. That makes the resulting file auditable rather than mysterious, which matters when the next system that reads it is a tax portal, an e-invoice endpoint, or an internal reconciliation script.
Why GST Data Often Lives in Excel Before It Becomes JSON
Indian GST workflows almost always begin in a spreadsheet. Tax practitioners maintain invoice registers, HSN-wise summaries, and GSTR-1 or GSTR-3B working sheets in Excel because that is the medium most teams already know how to audit, version, and share. Once that data needs to move — uploading to the GSTN portal, pushing into an e-invoice API, feeding an accounting package, or driving a reconciliation script — the spreadsheet format becomes the wrong shape. APIs and developer tools expect JSON objects, not columned grids. So the practical handoff is to flatten the worksheet into one record per invoice line, where each record carries a GSTIN, an HSN code, a taxable value, a tax rate, a CGST, SGST, IGST split, and an invoice total.
Doing that flattening by hand is tedious and error-prone; doing it through a deterministic converter is faster and easier to review. When the source is already a clean working sheet, this single step is the bottleneck that prevents the rest of the pipeline from running. Once JSON exists, an e-invoice sandbox can validate the payload, a TypeScript schema can describe it, a reconciliation script can compare it against last month's data, or a developer can preview it directly in their browser before any of it reaches a tax portal.
Convert the GST Worksheet to JSON Locally
Open the Excel to JSON Converter in a browser tab. Pick the GST .xlsx workbook from disk — anything up to 20 MB and using the modern .xlsx OOXML format will load, while legacy .xls files, macro-enabled packages, password-protected files, and cloud URLs are explicitly rejected. The page checks the classic ZIP directory and the declared entry counts before it loads the SheetJS module, which keeps the browser from being asked to parse a package that is too large, too damaged, or stored in an unsupported container. Once the workbook reads cleanly, the converter lists its worksheets and asks which one to export.
Pick the sheet whose first row holds the stable field names — typically InvoiceNo, InvoiceDate, GSTIN, HSNCode, TaxableValue, CGST, SGST, IGST, Total. Every header must be non-empty and unique; duplicate keys would otherwise collapse onto each other inside a single JSON object. Each row below the header becomes one JSON record, with empty cells turned into null and stored text, number, and Boolean values preserved. Click Convert, then download the JSON file the tool creates in the same tab.
- Open the converter page in your browser and pick the GST .xlsx workbook from disk, confirming it is under 20 MB and a normal .xlsx file rather than .xls, macro-enabled, encrypted, or cloud-only.
- Wait for the worksheet list to appear after the ZIP directory check passes; legacy or damaged packages stop with an error rather than producing a partial result.
- Select the worksheet whose first row holds unique, non-empty field names — for example, InvoiceNo, GSTIN, TaxableValue, CGST, SGST, IGST, Total.
- Click Convert to produce the JSON, then download the file the tool creates in the current browser tab.
- Open the downloaded file once in a text editor or a JSON validator and inspect three or more records before passing the file to the next system.
Prepare the Worksheet Headers Before Conversion
A clean header row is the single biggest determinant of usable output. The converter refuses to invent field names, so whatever the spreadsheet's first non-empty row says is exactly what the JSON keys will be. That means an HSN summary sheet titled "Apr-25 HSN" instead of "HSNCode" becomes {"Apr-25 HSN": "..."} in the output, which downstream code cannot validate against a stable schema. Renaming a row of header cells before exporting takes about a minute and removes a major source of integration bugs.
- Delete blank rows above the header row. Anything before the first non-empty row is treated as data, not labels.
- Replace merged header cells with one logical header per column. Merged cells appear as the same value repeated across adjacent cells.
- For dates, store the value the way Excel stores it. The converter does not guess locale or intent — a date written as 01/04/2025 in the cell goes out the same way.
- For GSTIN numbers that begin with a leading zero, set the cell format to text first, so Excel does not strip the zero during the export.
- If the workbook mixes invoice data with reconciliation notes on the same sheet, split them into two worksheets and export only the one with stable, unique headers.
What the JSON File Contains and What It Drops
The export is a values-only snapshot. Stored text, numbers, and Booleans appear as ordinary JSON values; empty cells become null. Everything outside that scope — formulas, macros, external links, embedded scripts, charts, images, comments, conditional formatting, named ranges, workbook protection, and formula source text — is intentionally not included in the output. A SUM formula on the Total column therefore exports whatever value was last saved into that cell, not a recomputation, which can be the older value if the workbook has been opened in read-only mode or never recomputed.
Formatting choices are likewise outside the JSON. Column widths, fonts, freeze panes, print areas, filter states, and cell colors do not survive, because they are spreadsheet concerns, not data concerns. If the team needs that fidelity for an audit copy, keep the .xlsx workbook itself as the source of record and use JSON only for the integration layer.
| Category | Preserved in JSON | Deliberately dropped |
|---|---|---|
| Cell values | Stored text, number, Boolean | Formulas — last saved value only |
| Empty cells | null | — |
| Headers | Unique non-empty first row | Merged multi-row headers |
| Sheet structure | One worksheet per export | Charts, images, comments, filters, named ranges |
| Workbook scope | Selected sheet only | Workbook protection, print settings, macros, external links, embedded scripts |
Verifying the JSON Output Before Sending It to an API
Before any JSON record reaches a GST portal or an e-invoice endpoint, two checks earn their keep. First, confirm the file parses as valid JSON using the same approach described in how to check if your JSON format is correct — locate any syntax error by line and column before the JSON ever reaches an API. Second, spot-check the first three and the last three records against the original worksheet, looking for headers that drifted, numeric values that lost a leading zero, or amounts that were stored as text rather than numbers.
A simple shape test is enough. Every record should carry the same set of keys; if one record is missing a key, the source worksheet probably had a stray empty cell mid-row. If the total amounts in the JSON match the workbook totals to the rupee, the conversion is usually clean enough to ship. The original .xlsx file is the source of record — keep it on disk so that any later dispute resolves against the spreadsheet, not the JSON export.
Common GST Worksheet Issues That Break the Export
Several GST worksheet patterns reliably break the export on the first attempt. Recurring pitfalls:
- Duplicate header names like Tax and tax — JSON treats keys as case-sensitive, so both go through, but rarely is that what the team intended.
- Rows of subtotals or grand totals mixed in with line items — those become "records" with their own numeric values and confuse downstream totals.
- A worksheet titled in the first cell with the header row on row 3 — the converter only looks at the first non-empty row, so the title cell reappears as a data field with its own key.
- Cells formatted as currency but containing stored integers — the integer is what gets exported, not a formatted two-decimal string.
- Password-protected workbooks, legacy .xls files, or cloud-only Excel URLs — the converter rejects these by design rather than producing a partial result.
For any of these, repair the worksheet first, then re-export. Quicker than reverse-engineering a partial JSON file later in the pipeline.