Logo file naming and version control for client handoff

1. Name what the file contains, not how finished it feels

A filename must still work after someone downloads one asset and forwards it without its folder. Start with the brand, then describe the composition and treatment: acme-logo-horizontal-white.svg is more useful than final-logo-7.svg. For a raster export, add a meaningful dimension such as 1600w, not a vague label like large.

Use a small controlled vocabulary. Choose horizontal or wide, not both. Choose symbol or icon and explain what it means. Keep separators and capitalization consistent, avoid characters your delivery systems reject, and preserve the real extension. Renaming a PNG to .svg does not change its contents.

Thoughtworks includes a descriptive logo filename in its published brand guidelines. The useful principle is that the name carries searchable information; your client does not need to adopt another organization’s abbreviations. Write your own token legend in ordinary language and test it with a colleague unfamiliar with the project.

Further reading: Thoughtworks brand guidelines: file naming, page 74

2. Separate design revisions from delivery releases

A working revision tracks your design process. A release identifies a reviewed package that someone can actually use. Those are different events. Your twentieth working file might become the first approved delivery; do not make clients interpret the entire revision history.

For example, keep acme-identity-working-r020.ai in your private working area and issue acme-logo-kit-2026-10-25-r01 as the delivery folder. Here r01 means the first issued package, not a software compatibility promise. Explain that convention once. Dates help ordering; they do not prove approval.

Freeze each issued package in your archive. If a correction changes geometry, a color treatment or a supplied export, issue r02 and record the reason. Do not quietly replace one file inside a previously approved ZIP while leaving the package name unchanged. You would lose a reliable way to establish what the client received.

3. Organize around the recipient’s first decision

A marketer may choose by placement or background; a production partner may choose by named job. Pick one main folder logic instead of nesting every possible property. For a small identity, folders for light-background and dark-background assets can be enough, with composition and format carried in filenames.

Keep editable source, delivery exports and explanatory previews visibly separate. Do not include rejected concepts beside approved choices. Store superseded releases in an archive outside the current download location, with access appropriate to the project; moving files must not accidentally broaden sharing.

4. Include a small release manifest

Put a readable start-here note at the top of the package. State the release identifier, issue date, approved variants, intended backgrounds and the location of the usage guide. Identify the owner who can approve changes. Include an asset list when the package is large enough that missing files would be difficult to notice.

Record meaningful changes rather than an internal diary: “r02 replaces the reversed symbol with the approved corrected artwork; horizontal full-color files are unchanged.” Say which earlier release it supersedes. If filenames remain stable across releases, the containing release folder and manifest must preserve that distinction.

For ongoing developer handoff, agree whether deployment references use stable filenames or versioned filenames. Do not rename assets already referenced by a live application without coordinating the change. The designer’s package archive and the developer’s deployment cache are related concerns, not the same version-control system.

Continue with: Plan the actual handoff contents

5. Test retrieval and replacement, not just spelling

Ask a teammate to find the white horizontal logo using only the delivered folder. Then ask which package replaces the previous one. If either answer needs your explanation, improve the names or the start-here note. A naming convention succeeds when another person can make the right decision quickly.

Compare the exported inventory against your approved asset list. Watch for duplicate basenames, mixed naming tokens, stale previews and an export tool adding unexpected suffixes. Open the files after downloading or extracting the exact package, not only from the source workspace. Confirm that names describe the real contents.

Before sending an update, prepare a short replacement instruction naming the old and new releases and the changed assets. Avoid “use the latest” when several folders can look current. Keep one clearly identified current delivery location, while preserving issued history separately.

Continue with: Keep export names aligned with approved assets

6. Package only the reviewed release

After approving the artwork and naming system, use logopack.app to prepare an organized export package, then review the result against your release list. A free account exports the supplied demo with its SVG artwork unchanged; exporting your own artwork requires a paid plan. Packaging does not approve new variants or repair a design.

Further reading: Open the generator · View current plans

Release checklist

• ✓Each filename identifies its brand, composition and treatment.
• ✓Raster dimensions in names match the files.
• ✓Working revisions are separate from issued releases.
• ✓The release identifier matches the manifest and download package.
• ✓Superseded assets are not offered as current choices.
• ✓A colleague can retrieve the requested asset without help.
• ✓The exact extracted delivery has been checked.