File Naming Conventions: Best Practices for 2026

By Michael Peters · Published 26 May 2026 · 7 min read

← Back to Blog

Why file naming conventions matter

The cost of bad filenames is invisible until you go looking for something. A folder of proposal_final.pdf, proposal_final_v2.pdf, proposal_FINAL_v2_updated.pdf and proposal-real-final.pdf is funny in the abstract and infuriating in practice. Multiplied across an organisation, inconsistent naming costs hours per week in confusion, misfiled drafts, sent-the-wrong-version mistakes, and broken automation. A naming convention is the cheapest possible piece of infrastructure: a one-page rule that pays back for years.

This guide sets out the conventions that survive contact with real production work — the ones used by document teams, regulated industries, and any organisation that has been burned once by a missing or mis-versioned file.

Core principles

A good naming convention satisfies five constraints simultaneously:

• Sortable. The default alphabetical sort in your file manager should produce a meaningful order — chronological, or grouped by project — without any extra effort.
• Identifiable. Someone seeing the filename in an email, a chat, or a log file should know what the file is without opening it.
• Machine-readable. Scripts, search tools, and automation should be able to extract structured information (date, project, version) from the filename reliably.
• Portable. The filename should be valid on Windows, macOS, and Linux, and survive being attached to email or uploaded to cloud storage without auto-renaming.
• Stable. Once a file is named, that name should not need to change as the file is moved, archived, or revised.

Most of the rules below exist to satisfy one or more of these constraints simultaneously.

Use ISO dates

The single most useful convention is to use ISO 8601 dates — YYYY-MM-DD. So 26 May 2026 becomes 2026-05-26. There are three reasons:

• It sorts correctly alphabetically. No other date format does. 26-05-2026 sorts before 26-05-2025 alphabetically, which is wrong.
• It eliminates US/UK ambiguity. 05-04-2026 is May 4th in the US and 5th of April in the UK. 2026-04-05 is unambiguous everywhere.
• It is parsed automatically by virtually every tool. Excel, search engines, programming languages, archival systems — all understand ISO dates without configuration.

If you only adopt one change from this guide, adopt this one. Put the ISO date at the start of the filename if you want the directory listing to sort chronologically; put it after the project code if you want grouping by project to take priority.

Use a consistent template

Define the template once and stick to it. A common, robust template is:

<date>_<project-or-client>_<descriptor>_<version>_<status>.<ext>

Concrete examples:

• 2026-05-26_ACME_proposal_v2_draft.pdf
• 2026-04-12_PROJ123_design-brief_v1_approved.docx
• 2026-03-04_OPS_quarterly-report_v3_final.pdf

Not every component is needed in every filename. The point of the template is that whichever components you do include, they appear in the same order with the same separators. Sorting and searching then behave predictably.

Avoid problem characters

The following characters cause problems across operating systems, shells, URLs, and cloud storage. Avoid them in filenames even if your current OS tolerates them:

• Spaces. They break URLs (becoming %20), require quoting in every shell command, and trip up older tooling. Use hyphens or underscores instead.
• Slashes / and \. Path separators — can never appear inside a filename.
• Colons :, asterisks *, question marks ?, angle brackets < >, pipes |, double quotes ". All reserved on Windows.
• Leading or trailing periods or spaces. Hidden on Unix, trimmed on Windows.
• Non-ASCII characters and emoji. They survive on modern systems but break under FTP, older email clients, command-line tooling, and many archive formats. Stick to ASCII for filenames intended to travel.

Within those constraints, hyphens and underscores are both safe. A workable rule: use underscores to separate logical sections of the filename (date, project, descriptor) and hyphens to separate words within a section (design-brief). Pick a rule and stay consistent.

Versioning

Use explicit version numbers rather than words like final or latest. Final almost never is.

• Single-digit versions for major iterations: v1, v2, v3.
• Decimal versions for minor revisions within an iteration: v2.1, v2.2 if you need them.
• Status tags for lifecycle stage: draft, review, approved, archived. These can change while the version number stays the same: proposal_v2_draft.pdf becomes proposal_v2_approved.pdf.

If you have version control software, use it for source-controlled material. File-system versioning is best reserved for documents that move between people via email, shared drives, or DMS systems — cases where the filename itself has to carry the version information because the system around it does not.

Length and readability

The hard limit on most systems is a 255-character path (filename plus its full directory path). In practice you want to stay well below that — long filenames are awkward in dialog boxes, get truncated in file managers, and look terrible in email attachments. Aim for filenames of 30–60 characters where possible.

The best way to keep filenames short is to push categorising information into the folder structure: a folder 2026/Q2/ACME/ means the filename inside it does not need to repeat 2026_ACME. The trade-off is that filenames lose their identity when copied out of the folder. Choose based on how files actually travel in your workflow.

PDF-specific considerations

PDFs are a particular case. Two extra things matter:

• The filename is not the document title. Acrobat displays the document title from the PDF's metadata (the /Title entry in the document information dictionary or in XMP) in browser tabs and on-page navigation. A well-named file should also have well-set metadata. See our guide on PDF metadata for what gets stored where.
• Filenames travel with PDFs into archives. Files in PDF/A archival format may be retained for decades. The name you give a PDF today might be the only way someone finds it in 2046. Make it descriptive enough to survive that timescale.

For high-volume PDF production — documents being generated, batched, or archived programmatically — the naming convention should be enforced by the generation tooling, not left to humans. We help organisations build that enforcement into PDF Library-based production pipelines and Acrobat batch processing workflows.

Migrating an existing mess

If you already have a folder full of inconsistently named files, do not bulk-rename them. You will break links, references, and people's mental maps. Instead:

1. Pick the convention and document it in one page.
2. Apply it to all new files from a fixed start date.
3. Rename old files only when you next touch them.
4. Tolerate the mixed state for as long as it takes for the new convention to dominate by volume.

A good naming convention is a forward-looking commitment. Trying to retroactively perfect the past is usually a waste of effort — the files that matter will be renamed naturally as work flows over them.

One-page template you can adopt

If you want a starting point, here is a convention that works across most knowledge-work organisations. Adapt it to your context:

Format:  YYYY-MM-DD_PROJECT_descriptor_vN_status.ext

Rules:
- ISO date (YYYY-MM-DD) at the start
- Project code or client code in ALL CAPS
- Descriptor in lower-case-with-hyphens
- Version as v1, v2, ... (with v2.1 etc for minor revisions)
- Status: draft | review | approved | archived (omit if not applicable)
- ASCII only, no spaces, no Windows-reserved characters
- 30-60 characters total where possible

Put that document on an internal wiki page, link to it from every onboarding doc, and revisit it once a year. That is genuinely all the governance most teams need.