Skip to content
Server-sideDeleted in 30 minutes

Convert ODS to CSV

An OpenDocument spreadsheet holds sheets, formulas and locale-aware formatting. A CSV holds rows of text. The conversion resolves formulas to values and exports the first sheet, and the detail worth knowing is the decimal separator: a locale that displays 3,14 writes 3.14 into the file, because a comma is the field delimiter.

Use this without the search next time. Prathom Workbench puts Prathom's tools in your toolbar.

Add to Chrome — free
ODSCSV

Drop your ODS file here, or click to browse

Up to 50 MB. Deleted automatically after 30 minutes.

What it does

  • The first sheet is exported; other sheets stay in the workbook
  • Formulas are written as their computed values
  • Decimal point rather than decimal comma, so fields do not collide with the delimiter

How to use ODS to CSV

  1. 1

    Upload the .ods

    A LibreOffice or OpenOffice spreadsheet. Move the sheet you need to the front if it is not already there.

  2. 2

    Values replace formulas

    The file records what the formulas produced, because a CSV has no calculation engine to re-evaluate them.

  3. 3

    Check numbers if you work in a comma-decimal locale

    The output uses a decimal point. A locale that shows 1.234,56 on screen writes 1234.56 to the file.

How it works

The ODS is unzipped, its content XML is read, and the first sheet's rows are written out as comma-separated values. Cells holding formulas contribute their cached result, because a data file cannot carry a calculation.

Fields containing a comma, a quote or a line break are quoted, which is the part that separates a proper export from a naive one.

The locale question

OpenDocument stores numbers in a locale-independent form and applies a display rule separately, which is why the same file shows 1,234.56 in one place and 1.234,56 in another. The stored value never changed.

CSV has no display layer, so the stored value is what gets written, using a decimal point. That is both correct and necessary: a decimal comma inside a comma-delimited file would make every number ambiguous.

What you get and what you leave behind

You get the data: rows, columns and values, in a form that databases, statistics packages and scripts read without configuration.

You leave behind the other sheets, the formulas as formulas, the number formatting, the charts and anything conditional. For a data handoff that is the right trade. For sending someone a workbook it is not, and XLSX or the original ODS is the better choice.

One sheet, no formulas, no formatting

CSV holds rows of values. An OpenDocument spreadsheet holds sheets, types, formulas, styles, charts and notes, so nearly all of it is left behind by definition rather than by accident.

The first sheet is exported. Formulas arrive as the values they last calculated, which is a genuine trap: the numbers look right and are frozen, so a workbook whose totals depended on a rate that changes will quietly keep the old rate forever.

Use CSV when something needs to read the data — a script, a database import, a statistics package. Keep the ODS when the workbook itself is the thing that matters, because the conversion cannot be reversed.

Delimiters and the machines that read them

CSV's separator is a convention rather than a rule, and the convention is not the same everywhere. In much of continental Europe the comma is the decimal mark, so spreadsheets there use a semicolon to separate fields instead.

A file written with one and read with the other does not fail cleanly — it lands every row in a single column, or splits numbers in half.

If the CSV is going somewhere specific, it is worth knowing which the destination expects before you send it. Most tools that read CSV let you choose, and the ones that do not are usually assuming a comma.

Examples

An analysis handed to a data team

analysis.ods - 4 sheets, first is the cleaned data
analysis.csv - first sheet, 8,900 rows

The team gets a file their tools parse natively. The three remaining sheets are working notes and stayed behind, which was the intention here but is worth confirming rather than assuming.

A workbook in a comma-decimal locale

budget.ods - amounts displayed as 1.234,56
budget.csv - 1234.56

The displayed format was a locale rule, not the stored value. Writing a decimal comma into a comma-delimited file would break every parser, so the point is used.

Frequently asked questions

Why is my decimal comma now a point?

Because the field delimiter is a comma. A locale that displays 3,14 is applying a display rule to a number stored as 3.14, and writing the displayed form into a comma-separated file would make every decimal look like two fields. The output uses the point, which is what essentially every parser expects. If a downstream tool needs the comma form it should be configured with a different delimiter, such as a semicolon.

Can I export a sheet other than the first?

Not directly, because a CSV holds exactly one table and the conversion has to pick. Move the sheet you want to the front of the workbook in LibreOffice, which takes one drag, and convert again. For workbooks where several sheets matter, converting to XLSX keeps all of them and lets the recipient choose.

Do cell formats come across?

No, and that is the point of the format rather than a shortcoming. A date shown as 3 April 2026 is stored as a number with a display rule; a currency amount is a number with a symbol attached for display. CSV records values, so the underlying data arrives and the presentation does not. Anything that needs a particular rendering should apply it after import.