| # | {{ 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 is still the handoff format many teams reach for when they need rows to move between spreadsheets, databases, exports, and scripts. That convenience comes from being simple text, but the same simplicity also removes a lot of context. A CSV file usually does not say whether the first row is a header, whether a value should stay text or become a number, or whether commas are even the real separator.
This tool is designed for that messy middle step between receiving a table and trusting it. You can paste CSV-like text or drop a text file, let the page parse it, and then read the summary badges, warnings, data preview, and column profile before deciding what to export. That makes it useful for migration prep, quick audits, documentation work, and small data cleanup jobs where you need a practical answer fast.
The page can keep the rows as arrays, turn them into keyed records, or render them as SQL, XML, HTML, Markdown, TSV, DOCX, or XLSX. It also lets you change delimiter rules, quote handling, header behavior, trimming, blank-row handling, null treatment, XML tag names, and SQL table name without sending the dataset through a server-side conversion step.
The main thing to remember is that CSV interpretation is partly conventional. Automatic header detection and type detection are helpful, but they are not authoritative. The safest workflow is to treat the first parse as a draft, confirm the structure in the preview, and only then rely on the keyed exports or download files built from it.
The core CSV rules are older and narrower than many real exports. RFC 4180 describes comma-separated rows, line breaks between records, and quoted fields where embedded quotes are escaped by doubling them. In practice, many business exports use semicolons, tabs, pipes, or custom separators instead, and some sources use single quotes or backslash-style escaping. This page accounts for that gap by supporting auto detection for common separators, manual selection for the usual alternatives, and a short custom delimiter when the source is more unusual.
Parsing starts by normalizing line endings so pasted text behaves consistently. In auto mode, the page samples the opening non-empty lines and scores comma, tab, semicolon, pipe, and space candidates by field count and consistency. It then parses character by character, only splitting when the chosen delimiter appears outside quoted content. If the file ends while a quoted value is still open, the run stops with an error instead of guessing. If some rows are short, the page keeps the data, pads the missing cells with blanks, and raises a warning so the preview stays rectangular.
Header handling is heuristic when you leave it on automatic. The first row is compared with later sample rows using signals such as keyword-like labels, uniqueness, text shape, and whether the first row looks more like labels than data. If that guess is wrong, you can override it directly. Once a header is active, the page also lets you change visible display labels and provide replacement field names so downstream keyed exports are easier to read and less likely to collide.
Type detection is intentionally limited. When it is enabled, the page can turn plain numeric strings into numbers, common boolean tokens into true or false, and literal null-like markers into null. Blank cells become null only if you enable that option. Date conversion is stricter still: only ISO-style dates are normalized when date detection is on. That restraint matters because identifiers, postal codes, account numbers, and region-specific date formats often look structured without actually being safe to coerce.
| Export family | Needs a header row | What the page produces |
|---|---|---|
| JSON Arrays | No | One array per row, preserving row order and any typed values already detected. |
| JSON records and JSON Lines | Yes | Keyed records built from the active header interpretation and any field-name overrides. |
| SQL INSERT script | Yes | A value-loading statement with sanitized table and column identifiers plus quoted literals. |
| XML | No | Rows wrapped in configurable root and row tags, with an optional row index attribute. |
| CSV and TSV | No | Delimited text built from the current export grid, including a header row only when one is active. |
| HTML, Markdown, and DOCX | No | Labeled table output based on the current display headers and parsed rows. |
| XLSX | No | A workbook built from the current export grid for spreadsheet review or handoff. |
| Area | What the page helps with | What you still need to judge |
|---|---|---|
| Structure | Delimiter selection, quote handling, row counts, irregular-row warnings, and preview trimming. | Whether the source export itself is complete and whether split rows reflect real data or a broken file. |
| Headers | Automatic header guess plus manual label and field-name overrides. | Whether the first row truly names columns or is actually the first record. |
| Typing | Numbers, booleans, null-like markers, and ISO-style date conversion when enabled. | Whether a value should remain text because leading zeros, codes, or local date formats matter. |
| Safety | A cleaner path from raw text to other formats. | Whether formula-like cells or risky text need separate sanitization before spreadsheet or database use. |
The profile tab adds a practical audit layer on top of the parser. For each column it reports dominant type, non-empty count, null count, blank count, a capped uniqueness estimate, and a sample value. That is enough to catch many common mistakes quickly, such as a supposed numeric field that still contains labels, an identifier column that should not have been converted, or a date column that stayed plain text because the source format was not ISO-like.
Processing stays in the browser for parsing, previewing, and text-based exports, and there is no dedicated server-side conversion endpoint for pasted CSV content. Standard page assets still load normally, and the XLSX export path fetches an extra browser-side library the first time you request a workbook. If the data is sensitive, you should still treat the browser session and any downloaded files as part of your data-handling boundary.
For most files, the best starting point is simple: paste the text, leave delimiter and header mode on automatic, and read the summary badges before touching any export tab. If the row count, column count, or header badge looks implausible, correct that first. A wrong structural read is more important than any later formatting choice because every export comes from the same parsed grid.
The next checkpoint is the preview table. If values appear shifted one column to the right, the delimiter or quote rule is probably wrong. If the first real record disappeared into the headings, header mode is probably wrong. If spacing looks inconsistent but the columns are otherwise correct, field trimming may be the only change you need.
| Situation | Best setting to check first | Reason |
|---|---|---|
| A European spreadsheet export uses semicolons | Set delimiter to semicolon | Auto detection often works, but explicit control removes doubt when commas appear inside values. |
| The first row is actual data, not labels | Set header row to treat all as data | This prevents keyed exports from silently dropping the first record. |
| Columns contain IDs, postal codes, or stock codes | Review type detection before exporting | Numbers may be convenient for analysis but destructive for values where leading zeros matter. |
| You need machine-friendly field names | Use the column naming overrides | This gives you cleaner keyed outputs without changing the source rows themselves. |
| The target is a report or document | Use HTML, Markdown, DOCX, or XLSX | Those exports are better suited to presentation and review than raw record interchange. |
Header-aware outputs deserve special care. JSON records, JSON Lines, and SQL are far more useful when the column names are correct, but they are also the quickest place for a bad header decision to cause damage. The column naming panel is helpful after the structure is settled because it separates visible labels from machine-facing names and lets you clean up awkward headings before export.
The profile view is the fastest way to judge whether automatic decisions were sensible. A column dominated by numbers should not show mostly text. A supposedly optional field should not have an unexpectedly high null or empty count unless the source really is sparse. A uniqueness count that looks too low may reveal duplicate identifiers, while a sample value that looks odd can expose a row-shift problem immediately.
Choose the final format by downstream job, not by habit. JSON Arrays are a good fit when row position matters more than labels. JSON records and JSON Lines are better for APIs, scripts, and log-style pipelines. SQL is useful for quick loading into a scratch table. XML is useful when the receiving system expects row tags. CSV, TSV, HTML, Markdown, DOCX, and XLSX are the better options when a person still needs to read, edit, or approve the result.
.csv or .txt file into the input area.A successful parse only means the text could be shaped into a table. It does not mean the table is correct. Trust the result only after the row count feels plausible, the warning badges are understandable, and the preview rows line up under the headings you expect. If any of those checks fail, treat every export built from that parse as provisional.
The profile tab should be read as a reality check rather than a schema contract. Dominant type tells you how a column behaves most of the time, not what it is required to be. A column can be mostly numeric and still contain one text label that matters. A uniqueness count can reveal repeated IDs, but it can also reflect a legitimately repeating category field. The sample value is often the quickest clue when the counts alone feel abstract.
Typed output deserves extra caution when values are identifier-like. A code such as 00127, a postal code, or a product number may look numeric but still need to stay text. The same applies to dates. This page only converts ISO-style dates when date detection is enabled, so a regional format such as 03/04/2026 should be treated as ambiguous unless you have already normalized it upstream.
Security and compatibility remain your responsibility after conversion. Spreadsheet applications can treat cells beginning with characters such as =, +, -, or @ as formulas, and this page does not neutralize that behavior for you. The SQL output is also a simple insert script, not a substitute for schema design, privilege review, or a database-specific loading policy. Use the exports as a bridge, not as a guarantee that downstream tools will interpret risky values safely.
You receive a contact list with headers such as name, city, and score. After pasting it, the page detects a header row and shows the right number of columns. The profile confirms that score became numeric while city stayed text. At that point JSON records or JSON Lines are a clean next step because each row now carries stable field names instead of positional values only.
A supplier sends a file that looks broken when read as comma-separated text because semicolons are the actual separators. Setting the delimiter manually fixes the shape immediately. A warning badge then shows that a few rows are short. Because the preview pads missing cells with blanks, you can still inspect the file, decide whether the gaps are acceptable, and export TSV or XLSX for manual correction.
A parts list includes item codes with leading zeros and a shipment date column in mixed text formats. Leaving type detection on would help for quantities, but it could also turn codes into plain numbers and leave the dates inconsistent. In that situation, review the profile carefully and consider turning off type detection or leaving date conversion off so the export keeps the source values as text until you normalize them elsewhere.
Sometimes the goal is not data loading at all. You may simply need a clean table for a report or knowledge-base article. After confirming the structure, use the display-label overrides to improve readability, then export HTML, Markdown, DOCX, or XLSX depending on where the table needs to land next.
Those exports need column names. If the page is treating every row as data, keyed outputs stay disabled until you enable a header row or provide labels another way.
The page keeps the dataset, warns about the irregular rows, and fills missing cells with blanks so the table remains rectangular for preview and export.
Date conversion is narrow on purpose. Only ISO-style dates are converted when date detection is enabled. Ambiguous regional formats are left as text.
No. The preview limit trims the interactive table only. The exported formats are still built from the full parsed dataset.
The parsing and conversion work happen in the browser and there is no dedicated conversion endpoint for the pasted rows. Standard page assets still load as usual, and the XLSX path fetches its workbook library when needed.