Prepare pasted lists, CSV and TSV tables

Decide whether the input is a list or a table

A list has one item per line. A table has a row for each record and a field for each property. If the text is just a series of cities, line-based tools are a good fit: you can remove a repeated city or add a bullet without changing anything else. If each line is a city followed by a country, a count and a note, the separators carry meaning. Removing duplicate lines or trimming punctuation at random can damage the relationship between those fields.

Start by saving a copy of the source. Look at the first line, three rows from the middle and the last line. Ask whether there is a header, whether one row is missing a value, and whether a cell can contain a comma or line break. Then decide how the next person will use it. Someone pasting into a spreadsheet may need tab-separated text. Someone reviewing values on a wiki may need a Markdown table. Someone importing to an application may need CSV or JSON with a particular structure.

If you cannot identify the record boundaries by looking at a small sample, ask for a fresh export with a documented format. A converter can parse a delimiter, but it cannot infer which column a stray value was meant to belong to.

Clean one-item-per-line input without changing names

For lists, start with the list formatter. Remove empty lines only if a blank line does not mark a new group. Keep the original order if it expresses priority. For example, an agenda might have “Review notes” before “Assign actions” for a reason, whereas a list of names for a public directory may be easier to scan alphabetically. Make a separate alphabetical version when someone still needs the original order.

Trim spaces at the edges of items before deciding what is a duplicate. The strings London and London can be functionally identical in a city list, but a leading space might be meaningful in an indented checklist. Decide whether case matters as well. ABC and abc may be two codes even if Paris and PARIS identify the same city in your source. The safest choice depends on what the lines represent.

After any removal, compare the before and after counts and inspect the eliminated items. Check the first and last entries; these are easy to omit while copying. Add a prefix or number only at the end, so the added marker does not interfere with matching earlier steps.

Filter and compare lists before rebuilding a table

The line filter is useful when each row is truly self-contained and there is a clear marker, such as lines beginning with a project code. Check whether the rule means “contains” or “exact match.” Searching for active as a substring may also select inactive. Test the rule on one item that should pass and another that should not, then examine the result before replacing your source.

For two independently copied lists, use the list comparison tool to find shared entries and items unique to each input. Use a common key where possible. A full record with a note added is no longer the same text even if its identifier is unchanged. If you are reconciling two tables, compare a deliberately extracted identifier column first, then use the original tables to see how individual properties changed.

Filtering raw CSV as if each visible line were a row is unsafe if quoted cells can contain line breaks. It can remove half of a record and leave unbalanced quotes. Parse or import that table first, then filter records by column in the destination. The same caution applies to removing repeated lines from a structured export.

Identify the separator using the source, not appearance

CSV typically uses commas, TSV uses tabs and some exports use semicolons. A sheet copied to the clipboard often produces tabs that are visually indistinguishable from wide spaces. A file using decimal commas may use semicolons as separators. Start with the exporter settings if you can find them. Open a small sample in the converter, choose the delimiter explicitly when detection looks wrong and compare the parsed columns with the original sheet.

name,city,note
Ana,Leeds,"Call after 16:00, local time"
Maya,Boston,"Bring the ""original"" copy"

The comma inside Ana's quoted note does not separate fields. The double quotes around the word original are escaped with two quotes. Changing every comma to a tab would turn the note into extra cells. Use a CSV parser to read fields, then let the converter serialize those fields with the destination separator.

Rows with a single filled column, rows that have many empty cells and short examples with no headers can make detection uncertain. A field count based on a manual reading of the header and two representative rows is a better check than assuming the first preview is right.

Open the CSV and TSV converter to check your separator

Handle quoted text and line breaks as data

A record can span multiple physical lines if a quoted cell contains a break. Think of a spreadsheet cell with a two-line delivery instruction: the underlying table has one row for the order, but a plain text editor shows two physical lines inside the quoted field. Do not collapse all breaks before parsing. Only the record separator outside a quoted field ends the row.

order,note
001,"Use the side door.
Call when you arrive."
002,Reception

If the converter reports a malformed quoted field, find the smallest snippet that reproduces it and compare it with the original export. Check for an unclosed quote, typographic quotes replacing straight CSV delimiters, or an accidental copy from the middle of a record. Do not repair the file by globally deleting quotes. They may be the only way to keep a comma or line break inside a field.

Different destinations accept different quoting conventions for tab-separated text. If your receiving tool does not handle multiline cells, decide whether to retain the original table and create a separate one-line-per-cell export. Replace a cell break only after parsing, and document that choice. Otherwise a reader may mistake the changed note for the exact original.

Convert a short sample and verify the quoted cells

Preserve headers, blank fields and leading zeros

Headers describe the columns and often become keys in a later conversion. Use names that distinguish values: invoice_id and customer_id are more useful than two columns both called id. When copying a subsection from a sheet, check whether the first row is really a header or the first record. A converter that uses a record as the header will make the output look complete while consuming one row of data.

Check cells such as 00123, phone numbers and long reference codes. These look numeric but may need to stay text. When opening the export in a spreadsheet, use its import controls to keep such columns as text. Verify the imported value, not just its display formatting. In the raw CSV Ada,,2026, the middle field is empty. Removing the second comma would shift the year into the wrong column.

Similarly, 0, a blank cell and a word like unknown can represent different states. Choose how the destination should distinguish them before sharing. If you must fill a missing value, record the change rather than assuming that every blank meant zero.

Catch uneven rows and unintended extra columns

Pick an expected width using the header or the import specification. Then inspect any row with more or fewer fields. An extra separator in an unquoted note and a deliberately empty last cell can look similar in a text editor but require different treatment. For instance, March,42, has three fields, the third empty; March,42 has only two. A receiving tool may pad the shorter row, reject it or read it differently. Do not rely on padding unless you have checked that behavior.

In a small sample, count columns after parsing rather than counting commas. A note can contain several commas without making the row wider. In a large table, validate widths in the import application or with a parser and make a short list of the exceptions. Look for a repeating source of the problem, such as a copied comment that was not quoted in one set of rows.

Fix the source or request a corrected export when you cannot infer the missing field safely. Hand-editing thousands of values based on a guess is a worse outcome than stopping with a clear error message. Test the corrected data with both a typical record and the row that failed previously.

Choose Markdown for a table people will read

If the destination is a README, a ticket or a wiki page, turn a compact table into Markdown with the CSV to Markdown table tool. Use a real header when you have one or let the tool generate labels for headerless input and then rename them. Pipes inside cell values need escaping so they are not interpreted as column boundaries. The tool also encodes literal markup characters and represents embedded breaks for a Markdown table; preview the destination because different renderers handle breaks and escaped characters differently.

Before pasting, decide how many rows the reader needs to see. A table with eight examples is often easier to review than a hundred-row export embedded in an issue. If the reader needs to reimport all rows, include a separate CSV or TSV rather than asking them to copy back a rendered table. A Markdown table is a presentation view, not a replacement for a structured source.

Check links, code-looking cell values and notes that contain a pipe. Also use a narrow preview if the destination will be read on a phone. For a wide table, you may need a smaller selection of columns or several tables focused on different questions.

Choose JSON when fields will be used by software

The CSV and JSON converter can make row objects when the first row supplies the keys, or arrays when the data has no stable headers. Decide which shape the receiving application expects. In object form, duplicate header names cannot usefully distinguish two separate columns. In array form, the meaning of a field comes from its position, so moving a column can change the meaning even when all the values are still present.

Review types after conversion. A CSV field has no universal rule that makes false a boolean or 0123 a number. Keep these as strings when they are labels or identifiers. Where a schema requires a number or boolean, convert only the affected columns using explicit rules and test blanks, negative values and unexpected spellings. Use the JSON formatter to make the result easier to inspect, but remember that syntactically valid JSON can still have the wrong shape for an import.

For a controlled handoff, share a three-row example with the expected output. Include one ordinary row, one empty field and one value that looks numeric but should stay a string. A small reference catches many misunderstandings before a large import.

Check how spreadsheets interpret imported content

When sharing a CSV with people who will open it in spreadsheets, text beginning with characters such as = can be interpreted as a formula. This is not fixed simply by writing the field in CSV quotes. A receiving spreadsheet may strip those quotes during import, then decide how to interpret the resulting value. Treat unexpected formulas as a reason to review the source and choose import settings deliberately.

If the records are supposed to be plain text, import into a test workbook with the affected columns set to text. Check an entry such as =not a formula as well as leading zeros and date-like codes. If your organization has an export policy, follow that policy rather than adding prefixes to every value by default. Adding characters changes the data, which can break systems that compare literal values.

Dates are another place where software can guess incorrectly. 03/04/2026 might mean March 4 or April 3. Ask for an unambiguous date convention when the date matters, and inspect the result on the recipient's actual import path. Keep a copy of the original export to resolve questions about values that changed on import.

Verify the destination before sending the full export

Run a round-trip check on a representative sample: convert it, open it in the destination, and compare a handful of values with the original. Include a comma in a note, an empty middle cell, a leading-zero identifier, a non-ASCII name and a multiline cell if present. Check the column count and order, then check the first and last records. This tests more than a successful converter message; it shows how the next application will actually read what you share.

For a team handoff, label the file with its delimiter, whether it has headers and which columns must stay text. If you send two versions, name them for their use, such as orders-for-import.csv and orders-preview.md. A preview table can be shortened, but the import version should not silently omit rows.

Keep your original export, the converted file and a brief note of intentional changes until the recipient confirms the result. If something goes wrong, regenerate from the original rather than converting repeatedly between formats. Start with a few rows now; when they arrive intact, use the same settings on the rest.

Open the table converter for your final sample