Final filenames should tell the recipient what a file is for and which version is current. A folder containing image1, final-new, and final-really leaves too much interpretation to memory. Use a concise naming pattern connected to the delivery matrix, with enough information to distinguish use, dimensions, language, and revision where those differences matter.
Choose fields that resolve real ambiguity
Start with a recognizable project or asset identifier and add the output role, such as header, card, poster, or layered-source. Include dimensions when several screen sizes exist, or language when copy varies. Avoid adding every possible property to every filename. The goal is quick identification of actual differences, not a long string that repeats information already fixed across the entire package.
Use a stable revision or date convention and apply it consistently. A shared identifier can connect the native source, review preview, and final outputs. Keep approved status clear in the package or accompanying note rather than appending final repeatedly as more corrections arrive. Modification timestamps alone are unreliable guides when files have been copied, downloaded, or resaved by another system.
Check filename restrictions for the receiving workflow. Some production systems limit length or special characters, and cross-platform exchange can expose inconsistent naming behavior. Use a practical supported character set and preserve the correct extension. Do not change an extension to make a file appear to be another format; the exported content must match the requested encoding or document type.
Preserve purpose through corrections and packaging
When supplying a correction, assign a new revision identifier and state which previous file it replaces. Keep the archived earlier delivery intact. Silent replacement can leave the recipient unsure whether a downloaded copy is current, particularly when several people integrate the asset. A brief replacement note is often more useful than a filename with another ambiguous suffix such as updated2.
Compare filenames with the actual file properties and content. A label saying transparent is misleading if the image includes a white background, and a name containing 1200x800 is wrong if an export preset produced another size. Open the file and verify. Names support delivery clarity but cannot substitute for inspection of the artifact they describe.
Keep review and annotated files out of the final asset set unless they are requested documentation. If included, identify their role clearly so no one publishes a marked preview. Separate working sources from flattened placement files when both are delivered. The recipient should be able to choose the right artifact for editing, placement, or reference without opening a sequence of similarly named candidates.
At close, compare the package against the delivery matrix and note the naming pattern in the delivery message if it needs explanation. Preserve the exact package in the archive. A good filename remains useful after the file leaves your folder, helping someone identify its intended use and revision while reducing the chance that a plausible-looking draft becomes the asset placed into production.