FfFilenameFixer
← All articles

Safe Filenames Before You Send: a 2-Minute Checklist

If you want safe filenames that open correctly for everyone, check five things before you hit send: no characters Windows forbids (\ / : * ? " < > |), no leading or trailing spaces or dots, a reasonable total length, a file extension that is still there, and accented, Korean or Japanese letters stored in composed (NFC) form rather than the decomposed (NFD) form a Mac often writes. The first four you can spot by eye. The fifth is invisible, which is why it causes the most confusion, and it is the one a free tool like FilenameFixer handles in a few seconds.

This article is the checklist version. It does not go deep into the Unicode theory; it is meant to be run through once, right before you attach a file to an email, drop it into a web form, or zip a folder for a colleague.

The safe filenames checklist

Run through this for every file you are about to send. Most files pass in seconds.

  1. Only ordinary characters. Letters, digits, spaces, hyphens, underscores, periods and parentheses are fine everywhere. Anything in \ / : * ? " < > | is not: Windows will refuse to save the file or silently alter the name.
  2. Nothing odd at the edges. No space or period at the start or end of the name. Windows strips trailing spaces and dots, which can turn report .pdf into something that no longer matches what you told the recipient.
  3. Keep it short. Windows has a historic limit of 260 characters for the whole path, folder names included. A 150-character filename that works on your desktop may fail inside C:\Users\Someone\Downloads\Project Materials 2026\....
  4. Extension intact. Invoice_March.pdf, not Invoice_March or Invoice_March.pdf.txt. If macOS is hiding extensions, check with Finder > Get Info.
  5. Composed Unicode (NFC) for non-ASCII letters. This is the one you cannot see. A file named José_contract.docx or 보고서.xlsx can be stored in two different byte sequences that look identical on a Mac. One of them breaks on Windows and in many upload forms.

If every item passes, send the file. If item 5 is in doubt, keep reading.

Why filenames break between Mac, Windows and web forms

Each system has its own rules, and files cross those borders constantly.

Forbidden characters

macOS lets you use almost anything in a filename except a colon (Finder shows a slash you typed as a colon under the hood). Windows forbids nine characters outright and also refuses names such as CON, PRN, AUX, NUL, COM1 and LPT1, with or without an extension. A file called nul.txt cannot be created on Windows at all. These are rare in practice, but Q3 Results: Draft?.xlsx is exactly the kind of name a Mac user types without a second thought.

Edge characters and length

Windows trims trailing spaces and dots when it saves a file. A ZIP that contains notes .txt may unpack as notes.txt, which is harmless, or the extraction may fail, which is not. Long paths fail for the same reason: the limit applies to the full path on the recipient's machine, not just the name you see.

The invisible one: NFD versus NFC

This is the item that generates most support requests. Unicode allows an accented letter like é to be stored either as one code point (precomposed, NFC) or as e followed by a combining accent mark (decomposed, NFD). The same applies to Korean syllables (한 can be stored as the jamo ㅎ, ㅏ, ㄴ) and to Japanese kana with dakuten or handakuten (が as か plus ゛).

macOS has historically written filenames in the decomposed form. The Mac displays them correctly, so the sender never notices. Windows, most web servers and many upload forms expect the composed form. When the file arrives, the result is familiar:

  • Zoë_CV.pdf shows up as Zoe¨_CV.pdf or with a stray box after the e.
  • 한글_보고서.pptx turns into separated letters like ㅎㅏㄴㄱㅡㄹ_....
  • 資料が.xlsx shows the dakuten detached from the kana.
  • A web form rejects the upload, or saves it under a name that no longer matches a database record.

The file itself is fine. Only the name is in a form the receiving system does not normalize.

How to check and fix filenames before you send

Here is a reproducible routine. Steps 1 to 3 cover the visible problems; steps 4 and 5 cover NFD.

  1. Rename the obvious ones in Finder. Select the file, press Return, and remove any of \ / : * ? " < > |. Replace with a hyphen or a space. Do the same for leading or trailing spaces and periods.
  2. Confirm the extension. In Finder, select the file and press Command-I. Under Name & Extension, make sure the extension is present and Hide extension is not masking a mistake such as a double extension.
  3. Shorten long names. If the name plus the folder path you expect on the other side is anywhere near 200 characters, shorten it now. Dates in YYYY-MM-DD form and short project codes keep names sortable without being long.
  4. Test whether the name is in NFD. You cannot tell by looking. Two quick options:
    • Developers: in Terminal, run python3 -c "import unicodedata,sys; print(unicodedata.is_normalized('NFC', sys.argv[1]))" "$(ls | head -1)" for a single file, or loop over a folder. False means decomposed.
    • Everyone else: open the free FilenameFixer web app at https://webapp-sepia-xi.vercel.app, paste the filename into the text converter, and compare the output with what you pasted. If the tool changes anything, the original was NFD.
  5. Convert to NFC. For a handful of files, drag them onto the FilenameFixer page in your browser; it batch-renames them to the composed form. The processing happens locally in the browser, so the files are not uploaded anywhere. For a folder you have already zipped, the ZIP restore tool can rewrite the names inside the archive (archives up to 200 MB). If you are a developer, unicodedata.normalize('NFC', name) in Python or str.normalize('NFC') in JavaScript does the same thing in your own scripts.

After step 5, re-run step 4. The output should now be unchanged.

Built-in alternatives that need no tool

You can avoid the problem entirely by naming files with plain ASCII when the content allows it: Jose_contract.docx instead of José_contract.docx, or report_kr.pptx with the Korean title inside the document rather than in the filename. This is honest advice and works for many office files. It is not an option when the name itself is the data, such as a scanned ID, a student's name on a submission, or a dataset where filenames are matched against a database.

Safe filenames for email, upload portals and colleagues

A few situations deserve their own line on the checklist.

Email attachments. Mail clients generally pass the filename through as stored. If you attach from a Mac without checking, the recipient on Windows gets the decomposed name. Rename or convert before attaching, not after the bounce-back.

Web forms and portals. Job application sites, university submission systems and government portals are where NFD causes silent failures: the upload appears to succeed, but the stored name is mangled or the form rejects the file with a vague "invalid filename" error. If you upload often, the FilenameFixer Chrome extension converts filenames automatically at upload time, so the checklist step happens without you remembering it. For one-off uploads, converting the file first is enough.

Files from Korean or Japanese colleagues. If a Mac-using colleague sends you files with Korean or Japanese names and they arrive broken, the fix is on the receiving end: drop the files or the ZIP into the web app, convert, and the names are restored. It is worth forwarding this checklist to the sender so the next batch arrives clean.

Developers and shared repositories. Normalize filenames to NFC in any script that writes files, and validate incoming uploads server-side. Do not rely on the client to send composed names; a filter that rejects NFD or converts it on arrival saves a lot of debugging later.

Limits worth knowing

A filename checklist prevents most breakage, but not all of it. Some systems have their own additional rules, such as SharePoint rejecting # and % in certain configurations, or older FTP servers choking on anything outside ASCII. Converting to NFC fixes the decomposition problem specifically; it does not shorten names, remove forbidden characters or repair files that were already renamed badly on the other side. And no tool can promise a given portal will accept a name, since each service decides its own validation. Treat the five checks above as the baseline, add the recipient's known quirks on top, and most of the "the file name is broken" emails stop arriving.