Where To Put A CSV File So Anyone Can Open It

You exported a spreadsheet, it came out as a .csv, and you emailed it to five people. Now there are five copies. One person got a single mangled column, another is asking whether the numbers changed since Tuesday, and a sixth needs it too but the file is too big for their mail server.

A URL fixes all of that, and putting a CSV file somewhere with an address is a small job. It has three traps in it that nobody mentions until you have hit them.

Not every host will serve the file at all. Browsers do not agree on what to do when they meet one. And Excel quietly rewrites your data on the way in, in ways nobody notices until somebody asks why a postcode lost its zero.

Here is where to put one, what happens when a person clicks the link, and the section in the middle you should not skip, because a published file is public and people keep customer lists in spreadsheets.

Where Can You Put A CSV File?

Anywhere that serves static files without filtering the type: most free static hosts, object storage, and the big file-sharing services. What separates them is whether you get a plain direct URL, and whether the host puts a viewer screen in front of it. If you have never put a folder on a static host before, the walkthrough for a single HTML file is the same three steps.

Pick based on who is at the other end. If a human will open it, a viewer page is a feature rather than an obstacle, and a shared drive lets you revoke access later. If a script will fetch it on a schedule, you want a bare URL, a path that never moves, and control of the header.

Why Some Hosts Refuse The File Outright

Because an allowlist is what stops a free static host turning into a file locker. If any extension can be uploaded and served, somebody signs up in ten seconds and mirrors pirated archives through it, and the whole domain gets flagged.

OxyPages runs exactly that kind of list, and it is short: HTML, CSS, JavaScript, JSON, PNG, JPEG, WebP, GIF, SVG, ICO, WOFF and WOFF2 fonts, and PDF, plus robots.txt and sitemap.xml at the root. A .csv is not on it. Neither is .zip, so archiving the data first does not get you around it. Publishing a document there means a PDF, and publishing data means a page.

That is a real limit, and better known now. If handing somebody raw rows is the whole requirement, use a host that serves any type.

What Happens When Someone Opens The URL?

It depends on one header the server sends alongside the file: Content-Type. The bytes on disk are identical either way. The header alone decides what the browser does with them.

• text/csv downloads. That is the registered type for the format and what most hosts send for the extension. RFC 4180, which defines text/csv
• text/plain displays the raw text in a tab, commas and all. Useful for a quick look, confusing for somebody waiting for a download.
• application/octet-stream always downloads, often with no useful filename attached.
• Content-Disposition: attachment forces a download whatever the type says, and can name the saved file.

No browser renders the rows as a table. Chrome, Safari, Firefox and Edge have no built-in spreadsheet viewer, so the best case is a download that opens in whatever the visitor's machine has associated with the extension. On a phone that might be nothing.

Whether you can change the header depends on the host. Object storage sets it per object, most static hosts let you declare headers in a config file, and simple file hosts do not let you near it.

Why Does Excel Turn Good Data Into Garbage?

Because Excel guesses. Double-click the file and it decides the delimiter, the encoding and the type of every column without asking, and it goes wrong in four predictable ways.

• Leading zeros disappear. A postcode of 01234 opens as 1234. The same happens to phone numbers, account numbers and part codes.
• Long numbers become scientific notation. A 16-digit order id shows as 1.23457E+15, and past 15 significant digits the digits are genuinely gone, not merely hidden by formatting.
• The delimiter depends on the reader's locale. On a machine where the decimal separator is a comma, which is most of continental Europe, Excel expects semicolons between fields, so a comma-separated export lands in one column. Same data, different laptop, different result.
• Accented characters break without a byte order mark. UTF-8 with no BOM gets read as the local legacy codepage, so Zürich arrives as Zürich.

There is a fifth habit: anything shaped like a date becomes one, and that is not a small problem. A 2016 study of published genetics papers found gene names corrupted this way in roughly a fifth of them, and the naming committee eventually renamed the genes rather than keep fighting the spreadsheet. Gene name errors are widespread in the scientific literature

So if Excel users are your audience:

1. Save as UTF-8 with a BOM. In Excel the export option is called "CSV UTF-8". It is the difference between readable names and mojibake.
2. Tell people to import rather than open. Data, then From Text/CSV, then set every column that must survive intact to Text.
3. Quote any field that could be misread.
4. Or send a page instead, because none of this happens to an HTML table.

Why A Link Beats An Attachment

The same three reasons as any other file, and all three show up inside a week.

Size. Gmail refuses attachments over 25 MB and plenty of corporate mail servers stop lower, so the moment an export grows the message bounces for the people who needed it.

Version drift. The copy in somebody's inbox freezes the second you press send. A month later they are quoting numbers from a spreadsheet you have replaced twice.

No undo. You cannot update an attachment or withdraw one. A URL you can republish, and everyone who ever had the link sees the current numbers.

One thing a link will not give you is a download count. Static hosting statistics count HTML page views, not file fetches, so a hosted spreadsheet tells you nothing about who opened it. If that number matters, you need a service built for file delivery.

Never Put Personal Data On A Public URL

A file on a public URL is public. There is no password, no audit trail, and no such thing as "only the people I sent it to".

Anyone holding the address can open it. Anyone they forward it to can open it. A crawler that finds the link anywhere, in a public repository, a shared document, an exported chat, will index it, and then it is findable by people who were never sent anything.

So: no customer records, no email lists, no phone numbers, no home addresses, no order histories, no salaries, no student marks, nothing else that identifies a living person. An unguessable address is not access control. It is a guess, and under GDPR-style rules publishing personal data is a disclosure whether you meant it or not.

If the data identifies people, it needs a login in front of it: a shared drive with named access, or an application with real accounts. A static host cannot do that however long the address is, and neither can a password typed into a page, because the file still sits at its own URL underneath.

Safe to publish: aggregates, counts, anonymised ids, reference tables, price lists, opening hours, fixtures, public statistics. When in doubt, delete the columns you would not read out in a room full of strangers.

Show The Data As A Web Page Instead

An HTML table opens the moment somebody clicks the link. Nothing to download, nothing to open in Excel, and it reads on a phone.

<!doctype html>
<html lang="en">
  <head>
    <meta charset="utf-8" />
    <title>Q3 Orders</title>
    <style>
      table { border-collapse: collapse; font: 15px system-ui, sans-serif; }
      th, td { border: 1px solid #ddd; padding: 6px 10px; text-align: left; }
      th { background: #f4f4f4; }
    </style>
  </head>
  <body>
    <h2>Q3 Orders</h2>
    <table>
      <tr><th>Order</th><th>Region</th><th>Units</th></tr>
      <tr><td>A-0417</td><td>North</td><td>128</td></tr>
      <tr><td>A-0418</td><td>South</td><td>94</td></tr>
    </table>
  </body>
</html>

Save that as index.html, drop the folder onto any static host, and the link works everywhere, allowlist or not.

Past about twenty rows, doing it by hand is miserable, so use a converter. The free browser tools here include a CSV to HTML table converter that adds sortable columns, a search box and a layout that survives a narrow screen, plus a CSV to JSON one for when the other end is code. Both parse the data in your browser, so nothing leaves your device.

JSON is worth a mention on its own. It is on far more allowlists, it carries one encoding rather than a guess, and no spreadsheet program reinterprets it on the way in. If a developer is consuming your data, ship JSON.

What To Do Next

1. Strip out every column that identifies a person. Do this first, not last, and on a copy.
2. Re-save as UTF-8 with a BOM if Excel is going to open it, and quote the fields that must survive intact.
3. Decide who is at the other end. A person gets a page. A script gets a stable URL and, ideally, JSON.
4. Convert the rows into a table, then publish the page and take the link. It costs nothing to try, and the address works over HTTPS straight away.
5. Send the URL instead of the attachment, and update the page in place when the numbers move.

If the raw rows really are the deliverable, keep them on a host that serves any type and put a one-page summary in front of them.