Updated 2026-10-18
How to Open a CSV File in Notepad++ (and Read What It Shows)
To open a CSV in Notepad++, drag the file onto the window, press Ctrl+O, or right-click the file and choose Edit with Notepad++. You get plain text with the delimiters still in place, not a table. That is the point: you are looking at the file as stored, before any spreadsheet decides what the columns mean.
Quick answer
A CSV file is a text file. RFC 4180 describes it as records separated by line breaks, with fields separated by commas and quoted when they contain a comma, a quote or a line break. Nothing in that description needs a spreadsheet to read it, which is why a text editor opens every valid CSV ever written, including the broken ones a spreadsheet refuses. Notepad++ adds three things a plain text editor does not: a visible encoding setting, a line ending converter, and the ability to render invisible characters. Those three cover most of the reasons people open a CSV outside Excel in the first place.
Three ways to open the file
- Drag and drop. Drop the file anywhere in an open Notepad++ window. Fastest for a file you are already looking at in Explorer.
- File, then Open. Ctrl+O, set the file type filter to All types if the CSV is not listed, and pick the file. Use this when the extension is unusual, for example a .txt or .dat export that is really comma separated.
- Right-click, Edit with Notepad++. Available when the shell integration was installed with the editor. This is the one to set up if CSV diagnosis is a recurring job, because it skips the open dialog entirely.
The file opens read-write. If you only want to look, use View or open a copy, because it is easy to leave a stray character behind in a file you meant to inspect. Nothing warns you on save that the structure changed.
What you should see, and what it means
The first line is normally the header. Each following line is a record. Commas sit between fields, and a field that contains a comma is wrapped in double quotes. If the file looks different from that, the shape of what you see tells you which layer is wrong.
| What you see | Likely cause | Where to fix it |
|---|---|---|
| Every record on one endless line | line endings not recognised, or no line breaks in the export | Edit, EOL Conversion |
| Semicolons or tabs where commas should be | the export used a regional delimiter | change the delimiter |
| Accented letters replaced by symbol pairs | UTF-8 bytes read as a Windows code page | Encoding menu |
| Rows that break in the middle of a sentence | a quoted field containing a real line break | leave it: that is valid CSV |
| Extra blank lines between records | trailing separators or padding from the export | remove blank rows |
The fourth row is the one people misread. A line break inside a double-quoted field is part of the field, not the start of a new record, so a description column with paragraphs makes one record span several visual lines. The quoting rules explain exactly when that happens and why the quote character has to be doubled inside the field.
How do I see the invisible characters?
View, then Show Symbol, then Show White Space and TAB, and again for Show End of Line. Tabs become arrows, spaces become dots, and each line ends in a visible CR, LF or CRLF marker. This is the fastest way to answer the two questions a CSV always raises: which character is actually separating the fields, and which line ending the file uses. A file exported on Windows normally ends lines with CRLF; a file from a Linux or macOS tool normally ends them with LF; the older Mac convention was CR alone.
If the fields are separated by something that is not a comma, you are not looking at a broken CSV, you are looking at a different dialect. Semicolon files are common in locales where the comma is the decimal separator. Tab-separated files are a separate format with their own media type. Both convert cleanly, and both are covered in the four delimiters CSV files use.
The encoding menu, and the trap inside it
The Encoding menu has two halves, and they do different things. The entries above the separator set how the bytes are interpreted. The entries starting with Convert to change the bytes on disk while keeping the characters you see. Picking UTF-8 from the top half of the menu on a file that is really Windows-1252 does not convert anything, it just reinterprets the same bytes and shows you mojibake.
The manual draws the distinction with a concrete example: a euro sign is the single byte 0x80 when converted to ANSI on a Western European code page, the three bytes 0xE2 0x82 0xAC when converted to UTF-8, and 0x20 0xAC when converted to UTF-16 BE with a BOM. Same character, different bytes, and only the Convert to entries change which one is on disk.
The BOM is the part that bites CSV files specifically. Notepad++ treats the byte order mark as metadata and does not display it in the editor panel, so you cannot see whether it is present by looking at the text. Convert to UTF-8 writes the file without one; Convert to UTF-8-BOM writes it with one. Many importers accept either, and some do not: a parser reading the file as plain UTF-8 will keep the BOM as part of the first header name, which is why a column called id suddenly cannot be found. We measured that on 2026-10-18 with Python 3.13.5: reading a BOM-prefixed file as utf-8 produced a first header of \ufeffid, and the lookup for id failed; reading the same file as utf-8-sig produced id.
The same measurement shows why the encoding menu matters before you save. A file written as UTF-16 and read as UTF-8 raised UnicodeDecodeError: 'utf-8' codec can't decode byte 0xff in position 0: invalid start byte. Nothing was wrong with the file. The reader had the wrong idea about it. Details of that failure mode are in CSV file encoding, and the visible symptom on the spreadsheet side is covered in fixing garbled CSV in Excel.
What a text editor cannot tell you
Notepad++ shows the file, not the table. It will not tell you that a column is supposed to be a date, that two records have a different number of fields, or that a value will lose its leading zeros once a spreadsheet touches it. Those are structural questions, and they need a parser rather than an editor.
A quick way to get both views is to read the file with a parser before you trust it. In our 2026-10-18 check, a semicolon-separated file parsed with a comma delimiter returned one field per row on every line: three rows, three records, no columns. Parsed with a semicolon it returned three fields per row. Same bytes, two very different answers, and the file itself never complains. Pasting the first rows into the CSV analyzer gives you the field count per row and the column widths, which is the check an editor cannot do.
There is also a size limit to respect. Notepad++ is a text editor with a full syntax-highlighting engine, and a multi-hundred-megabyte export is not what it is built for. If the file is too large to open comfortably, the problem is the size rather than the content, and opening a CSV that is too big for Excel covers the alternatives, including the CSV splitter.
A short workflow that avoids the usual damage
- Open the file and turn on visible white space and end of line.
- Read the header line and count the fields in it.
- Check that the next few records have the same field count. A mismatch is the bug, not a formatting quirk.
- Check the encoding in the status bar and convert only if the characters are wrong.
- If you edit, keep the delimiter, the quoting and the line ending as they were.
- Save, then verify with a parser or the analyzer rather than by eye.
That order matters. Most CSV damage happens when someone converts the encoding first, sees different characters, converts again, and saves a file whose bytes no longer match its content. Structure first, encoding second, edits last.
Notepad++ or plain Notepad?
Windows Notepad opens a CSV too, and for a quick look it is enough. What it does not give you is a visible encoding indicator, a conversion menu, or a way to render tabs and line endings, so the diagnosis above is guesswork in it. If the only question is whether the file contains text at all, Notepad answers it. If the question is which delimiter or which encoding the file uses, use Notepad++ or a dedicated viewer. The platform notes for the other systems are in opening a CSV in Windows and opening a CSV in Linux, and the general entry point is how to open a CSV file.
Frequently asked questions
How do I open a CSV file in Notepad++?
Drag the file onto an open Notepad++ window, use File then Open (Ctrl+O) and pick the file, or right-click the file in Explorer and choose Edit with Notepad++. All three open the same plain text. If the file appears as one long line, the line endings are not what this Windows build expects, and Edit then EOL Conversion fixes it.
Why does my CSV look like one long line in Notepad++?
Two causes account for most cases. Either the file uses a line ending Notepad++ is not displaying, usually LF from a Mac or a Linux export, or the file has no line breaks at all because the export wrote every record on one line. Use Edit then EOL Conversion, then View then Show Symbol then Show End of Line to see which one you are looking at. If the whole file really is one line, the records are separated by something else, and that is a delimiter problem rather than an editor problem.
How do I see the commas and tabs in a CSV in Notepad++?
Open View, then Show Symbol, then Show White Space and TAB, and separately Show End of Line. That renders spaces and tabs as visible marks and every line break as CR, LF or CRLF. It is the fastest way to tell a comma-separated file from a semicolon or tab-separated one, because the delimiter between fields becomes visible instead of looking like an ordinary space.
How do I convert a CSV to UTF-8 in Notepad++?
Use Encoding then Convert to UTF-8. The word Convert matters: the entries below the separator change the bytes on disk while keeping the characters you see. The entries above the separator only change how the existing bytes are interpreted, so picking UTF-8 there can turn readable text into mojibake without altering the file. Check the encoding in the status bar before and after.
Does saving from Notepad++ add a byte order mark to my CSV?
It depends which entry is active. Notepad++ treats the BOM as metadata and does not show it in the editor panel, so you cannot see whether it is there by looking at the text. Convert to UTF-8 writes without a BOM; Convert to UTF-8-BOM writes with one. If the Encoding menu shows UTF-8-BOM or one of the UTF-16 entries, the file will carry a BOM when saved.
Can Notepad++ show a CSV as a table with columns?
Not by itself. Notepad++ is a text editor, so it shows the record exactly as stored, with delimiters between fields. A CSV plugin installed through Plugins then Plugins Admin can add column alignment and linting, but the built-in view stays textual. That limitation is the reason to use it for diagnosis and a spreadsheet or a CSV viewer for reading data.
The CSV shows strange characters in Notepad++. What is wrong?
The file is being read in an encoding other than the one it was written in. Accented letters turning into pairs of symbols usually means UTF-8 bytes read as a Windows code page; black diamonds or question marks usually mean the bytes were already lost before the file reached you. Use Encoding to try UTF-8 and the UTF-16 entries, and if none of them restores the text, the file needs to be re-exported from the source rather than repaired.
Is it safe to edit a CSV in Notepad++?
For small, targeted edits, yes, as long as you keep the structure intact: the same number of fields on every line, quotes around any field that contains a comma, a quote or a line break, and the same encoding on save. A text editor will happily let you save a file that no longer parses, which a spreadsheet would have prevented. Check the result with a parser or the CSV analyzer before sending it anywhere.
Sources
- Notepad++ User Manual, Encoding (Encoding menu, the Convert to entries, the euro sign byte example, BOM handling, autodetection).
- IETF, RFC 4180: Common Format and MIME Type for CSV Files, section 2 (records, fields and quoting) and section 3 (the text/csv media type).
- Our own measurement, 2026-10-18, Python 3.13.5: BOM-prefixed file read as utf-8 gives a first header of \ufeffid; UTF-16 file read as utf-8 raises UnicodeDecodeError on byte 0xff; semicolon file parsed with a comma delimiter yields one field per row.
Related reading
Check the file before you open it
The CSV analyzer reads the first rows and reports the header, the field count per record and each column width, so a delimiter or encoding problem shows up as a number instead of a guess. If the delimiter is the problem, the delimiter converter rewrites the file without touching the fields.
Related reading
CSV Fundamentals — other guides that pair well with this one.
- How to Open a CSV in R
- How to Open a CSV File in Windows (Notepad, Excel, PowerShell)
- Convert CSV to PDF
- Convert CSV to Excel Without Excel
Browse all guides in the NoCodeCSV blog.