| # | {{ header }} | Copy |
|---|---|---|
| {{ row.index }} | {{ cell }} | |
| No rows to display. |
| Column | Key | Type | Non-empty | Null | Empty | Unique | Sample value | Copy |
|---|---|---|---|---|---|---|---|---|
| {{ profile.index }}. {{ profile.label }} | {{ profile.key }} | {{ profile.type || 'empty' }} | {{ profile.nonEmpty.toLocaleString() }} | {{ profile.nullCount.toLocaleString() }} | {{ profile.emptyCount.toLocaleString() }} | {{ profile.unique.toLocaleString() }} | {{ profile.sample || '—' }} | |
| No columns profiled yet. | ||||||||
null markers. Empty counts represent blank strings after trimming.{{ sqlInsertText }}{{ xmlText }}{{ htmlTable }}{{ markdownTable }}{{ tsvText }}CSV, or comma-separated values, is one of the simplest ways to move tabular data between systems. That simplicity is useful, but it also means the format carries very little built-in meaning beyond rows, fields, and quoting rules. This tool helps you inspect a CSV-like text file, decide how the rows should be interpreted, and reshape the same data into formats that are easier to load into applications, documents, and scripts.
It is especially useful when the source data is messy rather than formally wrong. A file may open fine and still have the wrong delimiter, a missing header row, uneven field counts, or values that look numeric in one row and textual in another. Seeing those issues before an import saves more time than discovering them later in a database table, dashboard, or automation job.
The package accepts pasted text and dropped text files, then immediately builds a preview with row and column counts, header status, delimiter feedback, warning badges, and a column profile. From that same parsed dataset, it can produce JSON arrays, JSON objects, JSON Lines, SQL insert statements, XML, HTML table markup, Markdown tables, TSV, CSV copy or download, a DOCX export, and an XLSX workbook.
A practical use case is preflight review before a migration. You might receive a customer export from a spreadsheet, confirm that the first row is really a header, rename one or two awkward columns, check that blank values are being treated the way you expect, then hand off JSON or SQL to the next system. Another common use case is documentation, where the HTML, Markdown, or DOCX outputs save you from rebuilding the same table by hand.
The main caution is that CSV interpretation is partly conventional, not absolute. Header detection and type detection in this tool are helpful heuristics, not a canonical verdict on what your source system intended. The safest workflow is to use the automatic decisions as a starting point, then confirm them against the data preview and warning list before you trust any downstream export.
In the simplest workflow, paste the text, leave delimiter and header detection on automatic settings, and read the summary badges first. If the row count, column count, or header badge looks wrong, stop there and fix the interpretation before exporting anything. A quick glance at the preview table usually tells you whether a delimiter split went wrong or a header row was mistaken for ordinary data.
The advanced settings are useful when the source file is unconventional. You can force a delimiter, supply a short custom delimiter, choose whether quotes are double, single, or disabled, decide how quoted escapes should behave, and control whether empty lines are skipped. Trimming fields is particularly helpful when imports fail because of invisible leading or trailing spaces rather than obvious content problems.
Header handling is where many conversions succeed or fail. If the first row is clearly labels, the object-style outputs become much more useful because JSON objects, JSON Lines, and SQL inserts can name columns instead of relying on position alone. If the first row is really data, forcing header mode would shift the whole dataset and quietly remove a record. The column override table is there for the middle ground where labels exist but need cleanup before export.
The profile tab is the fastest way to decide whether the parse feels trustworthy. It shows the dominant type per column, counts of non-empty, null, and empty cells, a uniqueness estimate, and a sample value. That makes it easy to spot a date column that stayed plain text, a supposedly numeric column that still contains labels, or a mostly empty field that should perhaps be dropped before import.
Choose the export family based on the job you are trying to do. JSON arrays are useful when order matters more than labels. JSON objects and JSON Lines are better when each row should be a keyed record. SQL is convenient for quick insert scripts, XML for systems that expect tagged rows, and HTML or Markdown for reports. CSV, TSV, DOCX, and XLSX are better when the next step is still human review rather than API ingestion.
The parsing path starts by normalizing line endings so the text behaves like one consistent buffer. In automatic delimiter mode, the tool samples the first block of non-empty lines and scores comma, tab, semicolon, pipe, and space candidates based on how many fields they produce and how consistent those widths remain from line to line. If you choose a custom delimiter, the package uses that value directly and falls back to a comma only when the custom field is left blank.
Actual parsing is then performed character by character. The parser tracks whether it is inside quoted text, respects either repeated-quote escaping or backslash escaping, and splits fields only when the active delimiter appears outside a quoted region. If the file ends while a quoted field is still open, parsing stops with an explicit error. If rows have different widths, the tool records warnings, pads short rows with blank cells, and keeps the widest row as the column count.
Header detection is heuristic and multi-signal. The first row is scored using shared label keywords, uniqueness, token shape, proper-name patterns, and the difference between the first row's apparent data types and the types seen in later sample rows. That matters because real headers often look linguistically different from the values under them. Even so, the package always lets you override the decision because no heuristic can know the intent of every export source.
Type detection is similarly conservative. With type detection enabled, blank cells can become null when you ask for that behavior, literal true or false and yes or no tokens become booleans, decimal or scientific notation strings become numbers, and ISO-like dates can be normalized to ISO timestamps when date detection is enabled. Everything else remains a string. The tool does not infer schemas, create nested objects from dotted column names, or guess locale-specific number and date formats beyond those explicit rules.
Once the table is parsed, the package builds several parallel output views. JSON arrays keep row order without relying on headers. JSON object records and JSON Lines are emitted only when a header row is active. SQL output is an INSERT script, not a full table-definition generator, and it sanitizes table and column identifiers separately from value formatting. XML output uses normalized root and row names, with optional row index attributes, while HTML and Markdown exports turn the same preview rows into publishable table markup.
| Output | Header required | What it preserves |
|---|---|---|
| JSON arrays | No | Row order and typed values without needing column labels. |
| JSON objects and JSON Lines | Yes | Record-style output keyed by the active header interpretation and overrides. |
| SQL insert script | Yes | A direct value-loading statement using sanitized identifiers and formatted literals. |
| XML | No | Tagged rows with normalized element names and optional row indexes. |
| HTML, Markdown, TSV, CSV, DOCX, XLSX | No | The preview-oriented row grid, optionally including the active header row when one is in use. |
The profile system adds one more verification layer. For each column, it counts non-empty values, nulls, empty strings, distinct samples up to a cap, and dominant type categories such as numeric, boolean, date-like, text, object-like, null, or empty. This is not deep statistical profiling, but it is enough to catch many practical problems before you export a misleading dataset.
Privacy and transport behavior are mostly local. The parsing, coercion, preview generation, and text exports happen in the browser, and the package does not submit your dataset to a server-side conversion helper. Standard page assets still have to load like any other site, and the workbook export path fetches an extra browser-side script the first time you ask for an XLSX file.
.csv or .txt file onto it.A successful parse is not the same thing as a trustworthy dataset. Start with structural checks: the column count should feel plausible, warning badges should be understandable, and the preview should not show obvious horizontal drift where one row's values are shifted under the wrong labels. If those basics are off, every export built on top of them will also be off.
Header-sensitive outputs deserve extra scrutiny. When JSON objects, JSON Lines, or SQL inserts are available, it means the tool currently believes a header row exists. That is useful, but it is also a reminder to confirm that the first row really contains labels and not just data that happens to look label-like. The profile tab helps here because mislabeled columns often reveal themselves as strange type summaries or improbable sample values.
Type conversion should be read as a convenience layer, not as schema enforcement. A numeric-looking string becoming a number may be exactly what you want for analytics, but it may be wrong for identifiers, postal codes, or codes with significant leading zeros. Likewise, ISO date detection is narrow by design. If the source uses ambiguous regional dates or mixed conventions, leaving those fields as text can be safer than forcing a guess.
Turning a spreadsheet export into JSON records. Paste a customer list where the first row contains labels such as name, city, and score. Leave header detection enabled, confirm that the preview shows those labels as headers rather than data, and then inspect the profile tab to see whether score became numeric and city stayed text. If everything looks right, the JSON object view gives you keyed records that are easier to pass into scripts or APIs than raw arrays.
Cleaning an irregular vendor file. Suppose one vendor sends semicolon-separated text with blank spacer rows and a few short records. Force the semicolon delimiter, keep empty-row skipping on, and read the warning badges. The warning list will tell you which rows have fewer fields than expected, while the preview shows the padded blanks. From there you can decide whether a TSV export is good enough for manual cleanup or whether the source file needs correction upstream.
Preparing documentation output. If the goal is a report or knowledge-base entry rather than an import, the HTML, Markdown, DOCX, and XLSX paths matter more than JSON or SQL. After confirming the header names, set a sensible preview limit, adjust display labels if needed, and export the table in the format that best matches the destination document.
Those outputs depend on having column labels. If the tool is treating every row as data, object-style exports stay empty by design. Switch the header mode or add a usable first row before expecting keyed records.
The parser keeps the file, warns about the mismatched row widths, and pads short rows with blank cells so the preview and exports remain rectangular. That keeps the dataset usable for inspection, but it is also a signal that the source may need cleanup.
The conversion work happens in the browser and there is no server-side helper endpoint for your pasted rows. Like any site, the page still loads its own assets, and the workbook export path fetches an extra browser-side script when you ask for an XLSX file.
No. It converts structure and formats values, but it does not certify the source as safe. If cells may begin with formula characters, downstream spreadsheet software can still treat them as formulas, and the SQL output is only a simple insert script rather than a full safety review of your data pipeline.