Sync Friendly across Linux, macOS, Windows, iOS & Android

What is the safest filename “allow list” that will work everywhere?

Use only:

• A–Z a–z 0–9
• space
• underscore _
• hyphen -
• dot .

That is the boring set that stays predictable across Windows, macOS, Linux, and mobile clients, and avoids characters that are reserved on Windows or troublesome in URL and WebDAV contexts. Sync tools like Synology Drive, NextCloud Sync etc will often skip or error on files that aren't suitable for the host OS. 

A simple policy version:

• Allowed characters: letters, numbers, space, _, -, .
• One dot for the extension (for example report.odt)
• No leading or trailing spaces or dots

#### Which characters should I never use?

Avoid these anywhere in a file or folder name:

• > : " / \ | ? *

They are Windows-reserved and are a common cause of sync failures or odd behaviour in cross-platform setups. 

Are dots safe? What about document..odt?

• A single dot before the extension is fine: document.odt
• Multiple dots can be technically valid but are best avoided for portability.
• document..odt is a bad idea because some layers treat .. as suspicious (path traversal patterns), and it can trigger URL, proxy, or security filtering issues.

Recommendation: avoid consecutive dots. Use document-v2.odt or document.v2.odt instead.

Can I use accented characters and non-Latin text (é, ü, 中文, etc.)?

Usually yes, but “usually” is not the same as “never breaks”.

If your goal is maximum compatibility with the least surprise (all desktops, all mobiles, browsers, WebDAV, random apps), prefer ASCII only (the allow list above). Non-ASCII can still be fine, but you are more likely to hit edge cases with older apps, odd encodings, or integrations.

A pragmatic compromise many teams use:

• Allow UTF-8 for user friendliness, but
• Be stricter for shared folders that must sync to everything, including Windows.

What about emojis?

Avoid them if you care about “will not break anywhere”. They can render inconsistently, sort oddly, and sometimes cause problems with older clients or integrations.

Are spaces OK?

Yes, spaces generally work on all major platforms but avoid if possible.

Two caveats:

• They can be annoying in command line scripts unless quoted.
• You must avoid leading/trailing spaces, because Windows normalises these in ways that can cause mismatch.

What names will break Windows even if the characters look safe?

Avoid Windows reserved device names (case-insensitive), even if you add an extension:

• CON, PRN, AUX, NUL
• COM1–COM9
• LPT1–LPT9

So do not use con.txt or nul.odt either.

Also avoid:

• Names ending in . or space
• Very long paths (deep folder nesting plus long filenames)

How long is “too long”?

Filesystem limits differ, but the practical limit is often hit on Windows first due to full path length constraints and application behaviour.

Safe, simple rule:

• Keep filenames under 150 characters
• Avoid very deep nesting
• Keep full paths “reasonable” (short folder names)

What is the recommended naming pattern?

A pattern that stays portable and readable:

• YYYY-MM-DD-Title_-_Topic_v2.ext
  Examples:
  • 2026-03-25_Meeting_Notes__Finance_v1.odt
  • Invoice_10482_-_Acme_Ltd.pdf
  • photo_2026-03-25_1405.jpg

What is the one-line “don’t break sync” rule?

Stick to:

• letters + numbers + space + _ + - + .
• no leading/trailing dot or space
• no ..
• avoid Windows reserved names
• keep names and paths short

An actual validator (regex) for this policy?

Here is a strict ASCII-only filename validator that enforces:

• allowed characters: A-Za-z0-9 _.-
• no leading/trailing dot/space
• at least 1 character
• (optionally) you can add a separate check for Windows reserved device names

^[A-Za-z0-9](?:[A-Za-z0-9 _.-]*[A-Za-z0-9_-])?(\.[A-Za-z0-9]+)?$

Things change over time, but generally this is solid constructive advice. Moving outside may work, may not, no guarantees.