Most contributors treat the filename as a label and the metadata as the real work. Agencies do not see it that way. Adobe Stock caps the Filename column in its contributor CSV at 30 characters, Shutterstock rejects a metadata sheet whose first column does not match the uploaded file exactly, and every FTP directory in the chain treats two identical names as one file. Naming is part of delivery.
The filename is a field, not a label
A stock file passes through more systems than most people count. It leaves your card with a camera-assigned name, gets edited and exported, picks up embedded IPTC data, appears as a row in a CSV, lands in an FTP directory, gets matched against a model release, and finally shows up in an agency's review queue. The filename is the only value that is present at every one of those stages. Keywords live in the file or the sheet. Titles live in the sheet. The name is the join key.
That is why naming failures are so hard to debug. A bad keyword gets rejected and you find out. A bad filename does not throw an error — it silently attaches the wrong release, overwrites yesterday's upload, or drops a row from a CSV that the agency then reports as "contains errors" with no line number. The cost lands weeks later, when a batch you thought was live turns out to be half a batch.
What the agencies actually enforce
Two agencies publish hard, checkable rules. Design for those two and the rest of your delivery list follows.
Adobe Stock: 30 characters, extension included
Adobe's contributor documentation sets the Filename column at a maximum of 30 characters and requires the exact filename including its extension. The same CSV is limited to 5,000 rows and 1 MB, and must be saved as UTF-8 — a detail that bites contributors using non-US versions of Excel. Title is capped at 70 characters and keywords at 50 per file, so the CSV is a tight document all round.
The rule worth memorising sits in the optional columns. Release filenames are also capped at 30 characters, and Adobe states that when multiple releases share the same filename, the system uses the most recent version. If you name every model release release.jpg, you are not attaching releases to shoots — you are attaching the last one you uploaded to everything. That is a licensing problem, not a housekeeping one.
Shutterstock: column A has to match, exactly
Shutterstock's CSV route puts the filename in column A, followed by description, keywords and categories. The platform checks the sheet against what you uploaded and rejects the whole file if the format does not match the sample, with a generic error rather than a per-row report. One renamed file after the sheet was written is enough to fail the batch. If you build these sheets by hand, the Shutterstock CSV template is worth having open beside you.
Everyone else: the FTP directory decides
Beyond the CSV-driven agencies, the filename becomes an addressing scheme. An FTP or SFTP drop folder has no concept of versions: send a file called final.jpg twice and the second one replaces the first, quietly. Send it to three agencies with three different names and your own records no longer tell you which asset is where. The mechanics of the transfer itself are covered in our walkthrough of uploading to Adobe Stock over FTP, but the naming discipline is the same on every host.
A convention that survives ten agencies
A good convention answers three questions from the name alone — which shoot, which day, which frame — in under 30 characters, using characters that no operating system or transfer protocol will mangle. Everything else belongs in metadata. Five rules get you there:
- Lowercase ASCII letters, digits and hyphens only. No spaces, no accents, no ampersands, no apostrophes. Spaces break command-line tooling and get encoded unpredictably in transit; non-ASCII characters are the most common cause of a CSV that looks fine locally and arrives corrupted.
- Date first, in ISO order: 260822 or 20260822. Sorting by name then sorts by time, which is what you actually want when you are looking for a batch you delivered three months ago. Day-month-year orders sort into nonsense.
- A short shoot code, three to six characters, that maps to a folder or a note somewhere. Not a description — a code. "kitchen-morning-light-woman" is a title; "kmw" is a filename component.
- A zero-padded sequence with room to grow: 0001 rather than 1. Four digits handles a 9,999-frame shoot and keeps alphabetical and numerical order identical.
- One name per asset, everywhere. The same file keeps the same name on Adobe, Shutterstock, Pond5 and your own drive. The moment a file has two names you have lost the ability to answer "where is this live?" without opening every portfolio.
Put together: 260822-kmw-0147.jpg — nineteen characters, sortable, unambiguous, and comfortably inside Adobe's limit with room for a suffix if you ever need one. Releases follow the same logic: 260822-kmw-rel-01.jpg ties the release to the shoot rather than to whatever was uploaded last.
Five naming habits that cost you re-uploads
- Shipping camera names. DSC_4471.jpg tells you nothing and collides the moment your counter rolls over or you add a second body. Two files called DSC_4471.jpg in the same FTP session means one file arrives.
- Versioning in the name. final, final2, final-v3-real. Version state belongs in your folder structure or your editing catalogue, not in the string an agency stores forever.
- Keyword stuffing. "business-woman-office-laptop-smiling-corporate.jpg" is 47 characters, will not fit Adobe's column, and gains nothing — no agency indexes the filename. It also duplicates work you are already doing in the keyword field, badly.
- Reusing generic release names. release.jpg, model.jpg, mr1.jpg. Adobe's own documentation says the most recent version wins when release filenames collide, so a generic name means every asset silently points at your newest release.
- Renaming after the CSV is written. The sheet and the files are checked against each other. Rename one file to fix a typo and the whole submission comes back as an error with no indication of which row was wrong.
Renaming an archive you have already uploaded
If you have a few thousand files under three different schemes, the instinct is to rename everything at once. Do not. Files already accepted by an agency are identified on that agency's side by the name you sent, and renaming your local copy does not rename theirs — it just breaks the link between your records and their portfolio.
The safe order is: freeze the old archive as-is, apply the new convention to everything from today forward, and keep a two-column mapping of old name to new name for anything you genuinely need to re-deliver. A CSV with old-name and new-name columns is enough. When you eventually retire a batch or re-upload it somewhere new, that mapping is what lets you do it without guessing.
The one exception is genuine duplicates — the same frame sitting under two names because it went out to two agencies at different times. Those are worth resolving before you scale up, and they are a naming problem more than an upload problem. We covered the detection side separately in how to avoid duplicate uploads across agencies.
Where naming meets the rest of the metadata pipeline
A name is an identifier, not a description, and it works best when the descriptive load is carried by embedded metadata instead. Title, description, keywords and copyright belong in the IPTC and XMP blocks inside the file, where every agency and every asset manager can read them — see photo tag basics: IPTC, XMP and embedded keywords for what goes where. Once the description lives in the file, the filename is free to be short and boring, which is exactly what you want it to be.
The same applies to releases and categories: they are matched by rules, and rules need predictable inputs. Our guide to categorisation and release attachment goes through the attachment logic in more detail, and almost every failure case in it starts with an ambiguous filename.
If you are delivering to several agencies at once, the naming convention also becomes the thing that lets you track status. Rastock AI generates metadata and delivers over FTP and SFTP to 10+ agencies, and it keeps the filename constant across every destination so the delivery log reads back cleanly — the feature overview walks through how metadata, per-agency formatting and delivery fit together. Nothing about that requires you to hand over ownership of your files or a share of your royalties.
A ten-minute setup
- Write your convention down in one line and stick it where you edit. Something like YYMMDD-shootcode-NNNN. If it is not written down it will drift within a month.
- Set it as an export preset in Lightroom, Capture One or whatever you use, so files are named correctly on the way out rather than renamed later.
- Check the length of your longest realistic name against 30 characters, extension included. If it does not fit, shorten the shoot code, not the sequence.
- Give releases their own pattern tied to the shoot code, and never reuse a release filename across shoots.
- Run one small batch end to end — export, CSV, upload, accepted — before you commit a month of work to the new scheme.
The short version
Filenames are cheap to get right at the start and expensive to fix later, because they are the one field every downstream system depends on and no system validates for you. Thirty characters, lowercase, date first, one name per asset, releases tied to shoots. If you want the naming, the per-agency metadata formatting and the delivery handled in one pass, Rastock AI has a 14-day free trial with no card required — the pricing page lays out the plans.
Frequently asked questions
How long should a stock photo filename be?
Keep it under 30 characters including the extension. That is the limit Adobe Stock publishes for the Filename column in its contributor CSV, and it is the tightest constraint among the major agencies, so a name that fits Adobe fits everywhere else. Count the extension: "-name.jpg" spends nine of your thirty characters before you describe anything.
Should stock photo filenames contain keywords?
No. Agencies read keywords from embedded IPTC data or from your CSV, never from the filename, so keyword-stuffed names burn the character budget you need for identification and gain nothing in search. Use the filename to tell you which shoot, which day and which frame it came from. Keep keywords in the keyword field, where they are actually indexed.
What happens if two stock files have the same name?
On an FTP or SFTP drop the second file overwrites the first, usually without any warning, so one of the two never reaches review. In a CSV workflow a duplicate name makes the row ambiguous and can fail the whole sheet. Adobe Stock is explicit about the release case: when several releases share a filename, it uses the most recent version.
Should I rename files I have already uploaded to agencies?
No. The agency identifies your asset by the name you originally sent, and renaming your local copy only breaks the link between your records and their portfolio. Freeze the existing archive, apply the new convention to new work, and keep a simple two-column mapping of old name to new name for anything you may need to re-deliver later.
Can filenames use spaces or non-English characters?
Avoid both. Spaces break command-line tools and get encoded inconsistently during transfer, and non-ASCII characters are a common cause of CSV files that look correct locally but arrive corrupted — Adobe requires UTF-8 encoding specifically because of this. Lowercase letters, digits and hyphens are safe on every operating system and every transfer protocol.
Does the filename affect how a stock photo ranks in search?
Not on the agency side. Stock marketplaces rank on title, description, keywords and performance data, and none of them index the filename you submitted. The filename matters for delivery integrity, release matching and your own ability to find an asset later. Search visibility is won in the metadata fields, which is where that effort belongs.