What you pasted is no longer the cell from the sheet
Everyone who has moved data has met this scene: a column of order IDs in Excel, copied as one block, pasted into the converter, and the exported JSON ends in different digits — 110101199003072316 comes out as 110101199003072320, still 18 digits long, only the last 2 refusing to match. The date column arrives as quoted strings, every row present, none of it usable as a number. The first guess is that the tool miscalculated. Count the digits one by one and you find something else: the damage happens twice, and the first time is already finished the moment you paste.
Only characters reach the text box. What leaves Excel is text rendered through the cell format, and that rendered text is all the tool ever sees: 2024/5/1, 12,345.00, 1.23457E+11, #N/A. Each one is already Excel's version of the value, and the tool has neither the means nor a basis to restore the date or the real number behind it.
Type inference recognises four kinds, and everything else lands in a string
In excel-to-json the only step that rewrites a cell is type inference, and its scope is integers, floats, true/false and null. Measured with "Auto-detect data types (numbers/booleans)" switched on:
| Cell as pasted | What the JSON shows | What happened |
|---|---|---|
2024/5/1 | "2024/5/1" | Outside the recognised set, kept as a string |
12,345.00 | "12,345.00" | Thousands separator read as text, 2 extra quotes |
1.23457E+11 | "1.23457E+11" | Exponent string kept verbatim, same either way |
#N/A | "#N/A" | Error values are strings too |
007 | 7 | Read as an integer, leading zeros dropped |
110101199003072316 | 110101199003072320 | Read as an integer, last 2 digits rewritten |
The four text shapes Excel has already rewritten — date strings, thousands separators, scientific notation, error values — sit outside the recognised set and are handed back as strings unchanged. What merely looks like an integer gets reworked instead: 007 → 7, 00 → 0, 1.0 → 1, 3.00 → 3, 12345.67890 → 12345.6789, -0 written as 0, with no notice anywhere in the interface. Mix bare values and quoted values in one file and how downstream code reads scalars becomes your problem; YAML and JSON scalar type rewrites covers the same set of traps.
Whether it drifts is decided by digit count and value together
Long numbers are usually explained as "too many digits", and the measurements say otherwise. All 3 samples inside 15 digits were exact. At 16 digits precision depends on whether the value crosses 2^53 (9007199254740992): among 16-digit inputs 9007199254740991 survives exactly as written while 9007199254740993 outputs 9007199254740992. From 17 digits 3/3 drift, at 18 digits the last 2 are rewritten more often than not, and a 19-digit value of all nines carries into 20 digits. Past that the question is no longer how many digits change: from 22 digits the JSON literal switches to exponential form, 1000000000000000000000 outputs as 1e+21, and the length shrinks from 22 characters to 5.
There are also rescued cases. Put one letter at the end (11010119900307231X) and the whole run stops being read as a number, so it stays a string — leaving one row of the same JSON as a number and the next as a string.
One switch keeps a whole column as written
Exactly one option preserves the pasted text across a column: turn off "Auto-detect data types (numbers/booleans)". Type inference short-circuits at the front, and all 48 measured inputs stayed strings once it was off. Draw the boundary clearly: what survives is the character sequence that arrived in the box, not the original precision of the cell. Neither switching on nor off turns 1.23457E+11 back into a number or 2024/5/1 back into a date.
Columns are cut on a hard-coded Tab, with no delimiter to choose
Splitting depends on a Tab written into the code and the page offers no delimiter control, so automatic delimiter detection is not a claim that holds up. Paste a CSV straight in and each line counts as 1 column — a,b,c gives one element, and in header mode the whole file collapses into 1 key. A quoted Tab inside a field is cut anyway: zhang<TAB>"xin<TAB>guo" yields 3 cells, and the quotes only remain characters sitting inside them. A newline inside a field breaks 1 row into 2; in header mode 2 rows of data become 3 objects, and from then on no column in the table lines up.
Duplicate headers and a first-column key shrink the rows, and the stats bar does not show it
Header cells become the key names of the objects, so duplicates collapse inside the JSON: name + name + city produce only 2 keys, and the value comes from the column written later, since a later write overwrites an earlier one. Three columns under the same name leave 1 key. An empty column name yields the key "", legal and meaningless. When there are more data columns than headers, the extras are dropped without a word.
Using the first column as the key is steeper. Five rows holding 3 distinct keys output 3 keys, and 2 rows of data disappear; the stats bar counts object keys and reports Rows: 3, so nothing hints at the loss. Numeric keys are reordered as well: pasted in the order 42, 7, 3, they come back 3, 7, 42.
The error box is almost never visible
Nearly every failure on this page is a silent structural change. Across 54 measured inputs the parse-error box appeared 0 times: blank-ish input is absorbed into the empty state first, and non-empty input always leaves at least 1 row, so neither throwing branch is reached. A single line in header mode returns only [] and Rows: 0, displayed like any other result, with no explanation attached.
Scale is not the worry, size is
There is no length cap and no truncation error: 2000 rows by 5 columns, 74669 characters of input, finished in one pass; the pretty output is 156672 characters over 14002 lines, the compact output 94671 characters. For the same data at 500 rows, pretty costs 15501 characters more than compact, about 1.7 times, and header mode costs another 15000 over plain arrays, because every key name is rewritten once per row. The 480px on the output side is only a viewing window; copying takes the full text. To weigh the two output sizes against each other, the pretty-versus-compact accounting in JSON formatting applies unchanged.
Four checks worth running after the conversion
- Read the longest numeric column against what you pasted, digit by digit: from 18 digits look at the last 2, from 22 digits look at whether it has taken a shape like
1e+21. - Match key count against column count: whenever a header is duplicated or empty, keys are fewer than columns.
- Match object count against pasted row count: a first-column key and newlines inside fields both break that equality.
- For every column that has to stay verbatim, run it once with the switch off and keep both results side by side.
Questions
Q: Can the date column be turned into a real timestamp?
It cannot. Type inference has no date branch, so 2024/5/1 stays a quoted string and a serial number such as 45412 is read as a plain integer. Neither is treated as a date.
Q: Does switching type detection off get the original precision back?
What it returns is the character sequence you pasted, not the value stored in the cell. Text like 1.23457E+11 was already an exponent string on the way in and remains a numeric string with the switch off; an 18-digit ID is only left untouched once the switch is off.
Q: Should I convert the CSV to Tab-separated text before pasting?
Yes. Tab is the only delimiter, and every other symbol makes the whole line read as 1 cell. Copy from the spreadsheet so the fields arrive separated by Tabs, and do not expect the converter to recognise commas.