How to create a systematic file naming and organisation strategy for your export brand's digital assets.
A Thai rice exporter's marketing folder contained files named "logo_final.png", "logo_FINAL2.png", "logo_v3_use_this_one.png", "catalogue_old.pdf", "catalogue_new.pdf", "catalogue_FINAL_for_print.pdf", "IMG_001.jpg" through "IMG_492.jpg", and a file called "untitled design (2).png". Finding the right asset was a daily scavenger hunt. When a Japanese buyer requested product photos, the exporter accidentally sent low-resolution thumbnail images instead of high-resolution files — because the file names gave no indication of resolution or quality.
File naming and organisation might seem like a trivial administrative detail, but it directly affects your brand's professionalism every time you share an asset with a buyer. A file named "catalogue_FINAL_v3_use_this_one.pdf" signals disorganisation. A file named "AcmeFoods_Catalogue_2026_EN.pdf" signals professionalism. The difference is a few seconds of thoughtful naming — but the impression lasts.
A good file naming convention includes the information someone needs to identify the file without opening it. At minimum, include: project or brand name, asset type, version or date, language or market code, and file characteristics (resolution, colour space for images). Use underscores or hyphens to separate elements — avoid spaces because they cause issues in URLs and some systems. Use PascalCase or camelCase for multi-word names to keep them readable without spaces.
Examples of good file names: "AcmeFoods_Logo_PrimaryHorizontal_2026_EN.svg", "AcmeFoods_Catalogue_RiceRange_2026_EN_Web.pdf", "AcmeFoods_Photo_JasmineRice_Hero_2026_300dpi.tif", "AcmeFoods_Presentation_TradeShow_2026_EN.pptx". Each file name immediately communicates its content, purpose, version, and format. Someone can find the right file without opening anything. Someone can tell from the name alone whether they are looking at the current version or an old one.
Document your naming convention and share it with everyone on your team. Include rules for: date format (YYYY-MM-DD is best for sorting), version indicators (use version numbers, not words like "final" or "old"), language codes (ISO 639-1: EN, DE, FR, ZH, JA, VI, TH), and prohibited characters (avoid spaces, special characters, and very long names). A documented convention ensures consistency even when different team members name files.
Your folder structure should mirror how your team thinks about and searches for assets. The typical top-level structure: Brand (logo, colours, typography, guidelines — rarely changes), Products (product photos, specification sheets, packaging files — updated frequently), Marketing (catalogues, brochures, ads, social media — campaign-based), Sales (proposals, quotations, presentations — deal-based), Templates (document templates, email signatures, social media templates — reusable), and Partner Kit (curated assets for external sharing).
Within each category, use subfolders that are specific enough to be useful but not so granular that navigation becomes tedious. A good rule: no more than three levels deep. For example: Products > Rice Range > Photos (not Products > Rice > White Rice > Premium > Photos > 2026 > Edited). Too many levels make files hard to find. If a category has many items, use alphabetical listing and consistent naming so scanning is easy.
Include a clear distinction between editable source files and final output files. Within each category folder, create two subfolders: "Editable" (AI, PSD, INDD, Canva template links) and "Final" (PDF, JPG, PNG, SVG). This prevents someone from accidentally editing the final file or sharing the editable source when they meant to share the final version. The Editable folder is for designers; the Final folder is for everyone else.
Version control is essential for assets that change over time — catalogues, product sheets, presentations. The simplest system: use date-based versioning (2026-05 for the May 2026 version) rather than sequential version numbers (v3, v4, v5). Date-based versions are self-explanatory and never ambiguous. When you update a catalogue, rename the old file with "2025" and save the new one with "2026". Anyone looking at the folder can immediately identify the current version.
Keep previous versions in an "Archive" folder rather than deleting them. This serves two purposes: you can reference old versions if needed (e.g., a buyer asks about a product that appeared in last year's catalogue), and you have a backup if a new version contains errors. Archive files with their original names plus the date they were archived. This prevents confusion about which version is current while preserving access to historical files.
When sharing files externally, always rename them before sending. A file named "AcmeFoods_Catalogue_RiceRange_2026_EN_Editable_v3.ai" should become "AcmeFoods_Catalogue_2026_EN.pdf" when sent to a buyer. Remove internal version information, editable status indicators, and any other internal metadata. The file the buyer receives should be clean, professional, and self-explanatory — never a raw internal file with cryptic naming.
Use language codes as the last element before the file extension: Acme_Catalogue_2026_EN.pdf, Acme_Catalogue_2026_DE.pdf. Keep the file name itself in English (your team's working language) and only the content changes per language. This makes it easy to find all language versions of the same document — they differ only by language code. For assets with translated file names (like a catalogue whose title differs by market), include the English name followed by the language code for internal use.
Use dates (YYYY-MM format or YYYY for annual assets) rather than sequential version numbers. Dates are self-explanatory — "2026" clearly indicates the current year's version, while "v3" requires you to know what v1 and v2 were and whether v3 is still current. Date-based naming also sorts chronologically in file listings. For assets that are updated multiple times within a month, add the specific date: 2026-05-15. For annual assets, just the year is sufficient: 2026.
Require external partners to follow your naming convention from the start. Include your naming guidelines in your onboarding package for new vendors. When you receive files with incorrect names, rename them before adding them to your library — never keep a designer's cryptic file name in your master library. Consider adding a prefix to external files: "EXT_DesignAgency_Logo_Variant_2026.ai" so you know the source if questions arise later.