4 min readConversions
Print a spreadsheet export as a document people can read
How to get a wide CSV onto a page without truncation, which delimiter and encoding problems break imports, and when a table should become a chart instead.
The short answer
Load the CSV, confirm the delimiter and encoding were detected correctly, choose which columns to keep and how wide each should be, then export a styled PDF with the header row repeated on every page. Wide data belongs in landscape or in fewer columns rather than shrunk until it is unreadable.
- Confirm the delimiter and character encoding before formatting, because both fail silently and corrupt the data.
- Repeat the header row on every page; a data table without headers on page four is unusable.
- If a table needs more than about eight columns on a portrait page, drop columns rather than shrinking the type.
A CSV is a transport format. It is excellent at moving rows between systems and poor at being read by a person — no formatting, no alignment, no page structure, and a header row that appears exactly once. Turning it into a document is a formatting job, and most of the work happens before the export.
Get the import right first
Two failures happen silently and ruin everything downstream, so check both before looking at anything else.
The delimiter. CSV is barely a standard. Files variously use commas, semicolons, tabs, or pipes, and European locales frequently use semicolons because the comma is the decimal separator. If the delimiter is wrong, every row collapses into one column, which is at least obvious. Worse is a file where commas appear inside quoted fields — an address, a company name — and a naive parse splits them into extra columns, shifting everything to the right from that row onward.
The character encoding. UTF-8 is the sane default, but exports from older
systems are frequently Windows-1252 or similar. The symptom is unmistakable once
you know it: accented characters render as pairs of odd symbols, é becomes
é, and currency signs turn into question marks.
The CSV conversion tool shows the parsed table before export. Read the first few rows and the last few rows there. Checking the end matters, because a quoting error partway down the file only shows its effects from that point on.
Decide what goes on the page
The most common mistake is trying to keep every column. A 20-column export squeezed onto a portrait A4 page gives each column about a centimetre, and the result is unreadable at any type size.
Be ruthless instead:
- Drop columns nobody reads. Internal identifiers, audit timestamps, and system flags belong in the CSV, not in the printed report.
- Shorten headers. "Transaction Reference Number" becomes "Ref". The reader understands from context.
- Go landscape when the data genuinely needs the width. This is the single most effective fix for a wide table.
- Split into two tables if the columns fall into natural groups.
A rough guide: about eight columns fit comfortably on portrait A4 at a readable size, and about fourteen in landscape. Beyond that, the document is a data dump rather than a report.
Formatting that makes a table readable
- Repeat the header row on every page. Non-negotiable. A reader on page four with no headers has to flip back constantly.
- Right-align numbers, left-align text. Right-aligned figures line up their decimal points, which is what makes a column of numbers scannable.
- Use consistent decimal places. Mixed precision within a column looks like an error even when it is not.
- Add banded rows on wide tables. Alternating shading stops the eye jumping lines.
- Keep the type at 8 points or above. Below that, printing becomes a struggle for a substantial share of readers.
- Give the document a title and a date. A printed table with no indication of what it is or when it was produced becomes useless within a week.
Watch for value formatting surprises
CSV has no types. Everything is text, and any interpretation happens at import, which is where data gets quietly damaged:
- Leading zeros disappear if a reference code is treated as a number, turning
00417into417. - Long numbers become scientific notation, so a card or account number turns
into something like
1.23457E+15. - Dates get reinterpreted, and
03/04/2026means two different days depending on locale. - Values that look like formulas may be treated as such.
Check a sample of these columns in the preview. It takes ten seconds and catches damage that is invisible in the finished PDF.
When a different tool fits better
- The source is a real spreadsheet. If you have XLSX rather than CSV, the Excel conversion tool preserves multiple sheets, existing formatting, and column widths you already set.
- The table is part of a larger document. For a report with commentary around the data, compose it in the document creation tool or in Markdown and place the table inside it.
- You are going the other way. Extracting a table out of an existing PDF is a harder problem, covered in the PDF to Excel guide.
One last point worth making: CSV exports are frequently the most sensitive files an organisation produces — customer lists, transaction histories, payroll extracts. Formatting one into a report is exactly the task where uploading it to a converter would be the least defensible. In this browser workflow, the row data is rendered on the device that opened or pasted it.
Tools used in this guide
Each workspace runs in this browser tab. Open one directly to apply the steps above to your own document.
Written by The PdfEditorOnlineFree team. Published and last reviewed . Product behaviour described here reflects the linked workspaces at the time of review; check the tool page for current limits.