Stock video download caps: why a B-roll-heavy calendar runs out first

A stock video subscription that felt generous in week one can be empty by the third week of the month, and the calendar that emptied it is often the one built on B-roll: a handful of longer takes, cut into short-form posts all month long. The plan did not shrink. The way it counts usage just does not match the way a short-form calendar consumes footage.

The plan meters downloads, not minutes

iStock’s own pricing page lists its Premium + Video subscriptions as a fixed number of downloads per month, shown in tiers of 10, 25, 50 and higher, sold on a monthly or annual billing cycle. The page states the allowance as a count of files, not a duration: “Downloads per month” is the line item, followed by a tier number, with no mention of clip length anywhere in that pricing table (iStock, plans and pricing, fetched 2026-09-09).

That structure means the meter does not care whether the clip you license runs four seconds or four minutes. One licensed video file is one download against the monthly allowance, the same unit a licensed image or illustration draws down. The page groups images and videos under the same “one download” language rather than giving video a separate, time-based counter (iStock, plans and pricing, fetched 2026-09-09). A team planning around “we get enough footage for the month” is planning around the wrong variable. The plan is sized in files, not seconds.

What a re-download of the same clip actually costs

The open question underneath this whole problem is what happens when you go back for a file you already have. If a team licenses one take on Monday, then returns to the library on Thursday to pull the identical file again for a different crop, does that second pull draw another unit from the monthly allowance, or does the standard license already cover reusing a file you hold without re-fetching it?

[EVIDENCE NEEDED: a direct statement from iStock on whether re-downloading an already-licensed file consumes a second download credit]. Neither the pricing page nor the license agreement, both fetched directly for this piece, address that question. The license agreement confirms that every file downloaded comes with a standard license and states seat and user restrictions in detail, but it does not say anything about the mechanics of pulling the same file a second time from the library (iStock, license agreement, fetched 2026-09-09).

Until that is confirmed one way or the other, the practical move avoids the question rather than answering it: keep the original file you downloaded, on a drive or in project storage, and re-export or re-crop from that local copy for every subsequent cut. Re-fetching from the library, whatever it costs, is optional. Re-editing a file you already hold is free by definition.

Why a calendar that cuts one clip five ways is the wrong shape for this meter

Picture two teams running the same short-form calendar off the same volume of finished posts. Team one searches the library fresh every time they start a new cut. A five-second product shot, a ten-second reaction shot, a fifteen-second wide, each pulled as its own search and its own download, even when two of those cuts could have come from the same longer take. That team spends one unit of the monthly allowance per cut, so five cuts in a week is five downloads, whether or not the underlying footage overlaps.

Team two works the other direction. They license a small number of longer takes, download each one once, and keep the source files on hand. Every short-form cut for the week comes out of local footage they already licensed. Instead of five downloads, that team’s week costs one, because reuse happens after the license is already secured, on the editing side, not the library side.

Same output. Same number of finished posts. Very different draw on the monthly cap. A calendar that treats every new cut as a reason to go back to the library is structurally the wrong shape for a meter that counts files, not minutes. A calendar that licenses fewer, longer takes and edits locally is the shape this pricing model rewards.

What actually happens when the cap is hit mid-month

  • The monthly allowance runs on the billing cycle, not the calendar month you happen to be tracking internally. iStock’s pricing page ties the download count to the subscription’s own cycle, whether that cycle is monthly or annual (iStock, plans and pricing, fetched 2026-09-09).
  • Once the allowance for that cycle is used, the pricing page’s own FAQ answer is that a file not covered by the current subscription can still be downloaded with credits, meaning a credit pack purchase, rather than waiting for the plan to reset (iStock, plans and pricing, fetched 2026-09-09).
  • The other option is simply waiting for the next billing cycle to begin, at which point the allowance refreshes.
  • Rollover changes how much slack a team carries into a heavy month. iStock’s FAQ states that unused downloads roll over, up to 250, but only for annual subscriptions or subscriptions with auto-renew enabled. If auto-renew is turned off before the term ends, any accrued rollover downloads are lost (iStock, plans and pricing, fetched 2026-09-09).
  • A non-renewing, month-to-month plan does not get that buffer. A team on that plan enters every month at the same fixed tier, with no cushion carried from a lighter month before it.

Questions to ask before assuming the plan is too small

  • Are cuts being re-pulled from the library when they could be re-exported from a file the team already downloaded and still has on hand?
  • Is the team licensing many short, narrowly-scoped clips to cover a week’s calendar, when fewer longer takes covering the same ground would produce the same finished posts?
  • Was the current tier chosen for a project-based workflow, a handful of downloads for a single campaign, rather than the steady weekly draw of a short-form content calendar? A tier sized for the former will look undersized against the latter even if the actual footage need has not grown.
  • Has anyone audited a month’s worth of downloads against the finished posts that used them, to see how many downloads per finished post the calendar is actually running at?

A note on license terms, not just the cap

Download-count mechanics and usage rights are two separate questions, and it is easy to conflate them when a plan runs out mid-month. How many times you can pull a file against your monthly allowance is a metering question, the one this piece covers. What you are allowed to do with a file once you have already downloaded it, where you can post it, whether paid promotion changes anything, is a licensing question, and a different one.

This site has a separate piece on what the licence says once a post is boosted, covering that second question on its own terms. The two should not be read as the same issue. Running out of downloads is a planning and workflow problem. What a licence permits after a boost is a usage-rights problem. Solving one does not touch the other.

Get more from a calendar built on downloaded footage

Followed exists to help teams get more out of the tools already in their stack rather than assuming the next upgrade is the fix. If the workflow questions above point to a re-download habit rather than a genuinely undersized plan, that is worth fixing before the next renewal, not after it.

FAQ

Does a stock video subscription count downloads by clip length or by file?

By file. iStock’s pricing page lists the monthly allowance as a count of downloads, in tiers such as 10, 25 or 50 per month, not a number of minutes or seconds of footage. A ten-second clip and a five-minute clip each consume one download the same way (iStock, plans and pricing, fetched 2026-09-09).

If I download the same stock clip twice, does it use two downloads?

[EVIDENCE NEEDED: whether re-pulling an already-licensed file from the library consumes a second download credit]. Neither iStock’s pricing page nor its license agreement, both fetched directly for this piece, state this one way or the other. The safer planning assumption is to keep the file you already downloaded and re-edit it locally rather than re-fetching it from the library.

Sources

Scroll to Top