Updated 2026-10-20

How to Open a CSV File on a Mac (Numbers, Excel, TextEdit)

Double-clicking a CSV on a Mac opens whichever app owns the .csv extension: Numbers, Excel, or a text editor that was installed later and claimed every plain-text type. A spreadsheet app shows columns, a text editor shows the commas, and neither is a broken file. When the columns come out wrong, the delimiter or the encoding is the cause, not macOS.

Quick answer

Right-click the file and choose Open With to pick the app for that one file. Use Numbers for a table, since it is on every Mac and its import settings expose the delimiter and the text encoding. Use TextEdit when you want to see the raw bytes. If the data lands in one column, the file is separated by something other than a comma. If the accents are wrong, the file is not UTF-8. Both are file properties, and both are fixable without touching the data.

Which app answers the double-click

macOS keeps one default app per file type. Install a code editor or a text editor and it may register .csv as a text type, which is technically correct and practically annoying: you get a wall of commas instead of a table. The assignment is not permanent:

• One file only: right-click, Open With, choose the app.
• Every file of that type: select one, File > Get Info, open the "Open with" section, choose the app, then click Change All.
• What a CSV actually is: plain text with one record per line and fields separated by commas, defined in RFC 4180. Nothing about that definition says spreadsheet, which is why a text editor is a legitimate handler.

What each app gives you

Why TextEdit shows one long line

First, the boring answer: a CSV record is one line. If the file has ten records you should see ten lines, each with commas in it. That is not a failure to parse, it is the format. TextEdit is not a spreadsheet and does not pretend to be one.

Second, the less boring answer. If you see a single unbroken paragraph, the file may have no LF bytes at all. Classic Mac software wrote records separated by a bare carriage return (CR, 0x0D), a convention that predates OS X. Modern tools split on LF (0x0A) and see one enormous record. RFC 4180 asks for CRLF, which is both bytes and satisfies everyone.

The test takes one command in Terminal:

wc -l export.csv    # 0 means no LF bytes: CR-only line endings

Numbers copes with CR-only files. Most web tools and every naive script do not, which is why a file that looks fine on the Mac a colleague sent it from can arrive as a single row everywhere else.

Why the whole file lands in one column

This is the most common Mac CSV complaint and it is almost never macOS. The file is separated by semicolons, tabs, or pipes, and the app is looking for commas. Semicolon exports come from locales that use the comma as a decimal separator, and they are normal in European data. Tab exports come from database and reporting tools that call the file a CSV anyway.

Excel for Mac makes this worse by being helpful. Microsoft documents the behaviour plainly: if the file is a .csv file, Excel opens it and displays the data in a new workbook, using the current default data format settings to interpret each column. There is no delimiter question, so there is no chance to answer it correctly. The same page gives the workaround, which is to change the extension from .csv to .txt before opening, because Excel runs its import wizard for text files.

If you would rather not rename anything, use Data > From Text/CSV. That path loads the file through a preview where the delimiter, the file origin, and the type of each column are set before the data reaches a worksheet. It is also the only path that protects long IDs and leading zeros, because the preview lets you declare a column as Text before Excel converts it to a number.

The full symptom-to-cause table for one-column files is in why a CSV opens in one column, and the delimiter itself is covered in the four delimiters CSV files turn up with.

Opening a CSV in Numbers, step by step

Numbers is the least surprising option on a Mac because it exposes the two settings that decide whether the import works. The steps, using Apple's own labels:

1. Open the file: File > Open, or drag it onto the Numbers icon in the Dock or the Applications folder.
2. Click anywhere in the imported table. In the Format sidebar, open the Table tab.
3. Click Adjust Import Settings. On the Delimited tab, tick the character the file uses under Separate Values Using, or type a custom delimiter.
4. If the accents are wrong, change the Text Encoding pop-up in the same panel. If the file has junk rows above the header, set where the data starts.
5. Click Update Table once the preview looks right.

Apple adds a warning worth reading before you start editing: import settings cannot be adjusted after you edit the imported table. Get the columns right first, then type. When you are done, File > Export To > CSV writes a comma-separated file, and Apple notes that the text encoding for the export is set under Advanced Options in that dialog, which matters if the next person to open it is on Windows.

The encoding trap: Mac Roman is not UTF-8

Text exported by older Mac software, and by some Mac-era databases, is written in Mac Roman rather than UTF-8. Both are valid text files. They do not agree on how to write an accented letter, and a file in the wrong encoding produces the classic two-character garbage instead of the letter you expected.

We encoded the same line, café,grüezi,naïve, in four encodings on 2026-10-20 and compared the bytes. The difference is not cosmetic: it is one byte versus two, and a reader that expects the wrong one either garbles the field or refuses the file.

Reading the Mac Roman file as UTF-8 fails at the first accented byte with UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8e in position 3: invalid start byte. Reading it as Mac Roman returns the string you wrote. In TextEdit, choose File > Open, select the file without double-clicking it, click Show Options, and pick the encoding from the Plain Text Encoding pop-up; Apple notes that the list can be extended with Customize Encodings List. In Numbers, it is the Text Encoding pop-up in Adjust Import Settings. The general subject, including the BOM that makes the first header read as \ufeffid, is covered in CSV file encoding.

Keeping leading zeros and long numbers

A CSV has no types. Every field is text. The moment a spreadsheet opens it, the app decides what each column looks like: a postal code of 01234 becomes 1234, a 16-digit card or account number loses its last digit, and a long number turns into 1.23E+15. Microsoft's own documentation names this case as a reason to import rather than open: converting a column of numbers that contains leading zeros to text preserves the zeros.

On a Mac the practical version is: import through Data > From Text/CSV and set those columns to Text in the preview, or open the file in Numbers and set the cell format to Text before you type or paste anything. If the file already went through a spreadsheet and the digits are gone, the fix is in keeping leading zeros in CSV, not in re-opening the damaged copy.

What we measured

Every byte figure above comes from a run on 2026-10-20, Python 3.13.5, on a Linux host. The bytes are the bytes a Mac file would contain; only the app that reads them differs. The commands and outputs are kept so the numbers can be re-run rather than trusted.

• Three-record file written with CR-only endings: 38 bytes, 0 LF bytes, 3 CR bytes. Splitting on LF returns 1 record. csv.reader on a string raises new-line character seen in unquoted field - do you need to open the file with newline=''? and returns 3 records when the file is opened with newline=''.
• Same accented line in five encodings: 21, 24, 18, 18 and 38 bytes, with the per-character byte values in the table above.
• Mac Roman file read as UTF-8: UnicodeDecodeError on byte 0x8e. Read as Mac Roman: the original string.
• UTF-8 file with a BOM read as UTF-8: first header comes back as \ufeffcafé. Read as utf-8-sig: café.

If you only need the table

When the goal is the data and not the app, skip the desktop entirely. The delimiter converter detects the separator and rewrites the file with the one you want, in the browser, without uploading it. The CSV analyzer shows the header, the field count per record and the width of each column, which is how you catch a trailing comma or a broken quote before a spreadsheet turns it into a silent one-column mess.

If you would rather see the rows as a grid without installing anything, the free CSV viewer route is one page and no account.

Frequently asked questions

Sources

• Apple, Numbers User Guide for Mac, "Import an Excel or text file into Numbers on Mac" (drag to the Numbers icon, Adjust Import Settings, Delimited tab, Separate Values Using, Text Encoding, Update Table, and the note that import settings cannot be changed after editing the table).
• Apple, Numbers User Guide for Mac, "Export to other file formats in Numbers on Mac" (CSV export and the text encoding setting under Advanced Options).
• Apple, TextEdit User Guide, "If characters aren't displayed correctly in TextEdit on Mac" (File > Open, Show Options, Plain Text Encoding, Customize Encodings List).
• Microsoft Support, "Import or export text (.txt or .csv) files" (a .csv opens straight into a workbook using the current default data format settings; renaming to .txt forces the import wizard; Data > From Text/CSV; the leading-zeros example).
• Microsoft Support, Excel specifications and limits (1,048,576 rows by 16,384 columns per worksheet).
• IETF, RFC 4180: Common Format and MIME Type for CSV Files, section 2 (CRLF record separator, comma fields, quoting).
• Our own measurements, 2026-10-20, Python 3.13.5: CR-only file byte counts and parser behaviour, and the byte values for one accented line in UTF-8, UTF-8-BOM, Mac Roman, Windows-1252 and UTF-16.

Related reading

Fix the file before the next app guesses

A CSV that opens badly on a Mac will open badly in the next tool too, because the problem travels with the bytes. Convert the delimiter and the encoding once and every app after that agrees with you.