You signed up for shared hosting because the plan said “unlimited storage.” Six months later you received an email from your host telling you that your account was consuming excessive resources. A year later your WordPress media uploads started failing. Now you are paying for a storage add-on that costs more per month than your original hosting plan.
This is not a coincidence. It is the predictable outcome of how shared hosting companies use the phrase “unlimited storage.” The word unlimited in that context does not mean what the English language would lead you to believe. It means something substantially different, and the difference is explained only in the terms of service that almost no one reads at signup time.
This guide explains what unlimited storage actually means in shared hosting contracts, identifies the four real limits that catch WordPress site owners by surprise, and explains the infrastructure approach that makes the question of hosting storage limits largely irrelevant for a WordPress site of any size.
What “unlimited storage” actually means in a hosting contract
Every major shared hosting provider that advertises unlimited storage includes a section in their terms of service that qualifies what unlimited means. The language varies between providers but the substance is remarkably consistent. Here are the actual terms from representative examples of what you will find if you read the fine print.
These are representative examples of the type of language commonly found in shared hosting ToS documents. The specific wording varies by provider but the substantive limitations are consistent across the industry.
The key phrase is “normal website files used in the ordinary course of operating your website.” This phrase is doing enormous work in these contracts. It is the mechanism that allows hosting companies to enforce limits on accounts that exceed their expected resource consumption without ever having stated a specific numerical limit. What counts as “normal” is entirely at the hosting company’s discretion.
A WordPress site with 50,000 product images that generates constant I/O from image serving is using storage in a way that, by any reasonable reading, exceeds what the hosting company modeled when it priced that unlimited plan. The hosting company did not expect a media-heavy WooCommerce store when it sold a plan designed for small business brochure sites. The “unlimited” offer was priced against that assumption, and when reality diverges from the assumption, the ToS provides the mechanism to recalibrate.
The four real limits hiding behind unlimited
Beyond the broad contractual language, shared hosting plans have four specific technical and policy constraints that catch WordPress site owners by surprise. Understanding each one explains why the unlimited promise breaks down for growing WordPress sites specifically.
An inode is a filesystem data structure that stores information about a file. Every file on a Linux server occupies one inode regardless of its size. Most shared hosting plans set a hard inode limit of 100,000 to 250,000 files per account. This limit is almost never mentioned in the marketing materials but is almost always present in the technical specifications buried in the hosting documentation or knowledge base.
Shared hosting servers throttle CPU and disk I/O at the account level to prevent any single tenant from degrading performance for others. When your WordPress site experiences a traffic spike and dozens of concurrent image requests hit the server simultaneously, the I/O throttle engages. Image requests queue up. Response times increase. From a user’s perspective the site becomes slow. From a technical perspective the storage is still “unlimited” — it is just serving that storage at a fraction of its theoretical speed.
Most shared hosting acceptable use policies explicitly prohibit using the hosting account as a file storage service, backup repository, or media hosting platform for content not directly related to a website served from that account. This prohibition is written broadly enough to potentially cover WordPress media libraries that exist primarily to serve images to a CDN, or large archives of old content that is no longer published on the live site.
Shared hosting is economically viable because of overselling: the assumption that most accounts will use a small fraction of their theoretical resource allocation at any given time. When a hosting provider sells 500 “unlimited” accounts on a server that can realistically handle 50 heavily loaded accounts, the math works as long as 450 of those 500 remain lightweight. As your WordPress site grows and its storage and I/O consumption increases, you become one of the heavier accounts. You experience slower performance not just when your own traffic spikes but when your neighbors’ traffic spikes.
Why WordPress sites specifically hit these limits
Shared hosting’s unlimited promise was designed around the resource consumption profile of a typical small business website in the mid-2000s: a few dozen HTML pages, some CSS, a handful of images, and maybe a contact form. A WordPress site with WooCommerce, a page builder, and two years of product catalog updates has a fundamentally different resource profile.
The table makes the pattern clear. The site types that hosting companies modeled when pricing unlimited plans are at the top. The site types that actually encounter the limits are at the bottom. WordPress and WooCommerce sites with active development histories occupy exactly the zone where unlimited plans break down. This is not a design flaw — it is the expected outcome of a pricing model built on assumptions that growing WordPress sites violate.
How to read a hosting ToS before signing up
Before signing up for any shared hosting plan that advertises unlimited storage, spend five minutes finding and reading the actual resource limits. Here is exactly where to look and what to search for.
Almost every shared hosting ToS or knowledge base that imposes inode limits will mention the word “inode” directly. Search for it. If you find a number (commonly 100,000 or 250,000), that is your real file count limit. If you do not find it, search for “file limit” or “file count” as alternatives.
The acceptable use policy is where the “normal website files” language lives. Read it carefully for phrases like “excessive resource consumption,” “adversely impacts other users,” or “file storage not related to website operation.” These are the contractual mechanisms the host will invoke if your site grows significantly.
Disk I/O limits are often specified in the technical specifications section or the resource limit policy. A limit of 1MB/s or 5MB/s per account sounds like a lot until you calculate that 50 concurrent users each loading a page with 30 images at 150KB each requires 225MB/s of I/O sustained. These limits are set to a fraction of what a busy WordPress site actually needs.
Why FTP offloading makes hosting storage limits irrelevant
The most direct response to the unlimited storage problem is to stop storing media on the shared hosting server entirely. When your WordPress media library is on an external FTP server and images are delivered via CDN, your shared hosting account holds only WordPress core files, themes, plugins, and the database. This footprint is dramatically smaller and falls well within what any shared hosting plan — limited or unlimited — can comfortably accommodate.
A WordPress installation without its media library typically uses 3,000 to 10,000 inodes: WordPress core files, one or two theme directories, and twenty to thirty plugin directories. This is so far below any hosting provider’s inode limit that the limit becomes completely irrelevant. The I/O pressure from image serving is entirely removed from the shared hosting server. The acceptable use concerns about media archiving disappear because there is no media archive on the hosting server.
WordPress core files: approximately 2,500 inodes
One active theme: approximately 300 to 600 inodes
25 plugins: approximately 2,000 to 5,000 inodes
Database (single file): 1 inode
Logs and cache files: approximately 500 to 1,000 inodes
Total without media: approximately 5,000 to 9,000 inodes
Compared to a 100,000 inode limit: you are using less than 10% of the theoretical limit. The unlimited storage problem is solved by moving the component that was actually causing it to a purpose-built storage server.
What to look for in a hosting plan once media is off the table
Once you have moved your media library to dedicated FTP storage and your hosting server is responsible only for PHP execution, the database, and static application files, your hosting selection criteria change entirely. You are no longer comparing storage allocations. You are comparing PHP performance, database speed, and support quality.
The number of concurrent PHP workers determines how many simultaneous WordPress page requests your hosting can process. A plan with 4 PHP workers handles 4 simultaneous dynamic requests; the 5th visitor waits. This is the limit that actually matters for WordPress performance once media is off the hosting server.
WordPress’s database query speed is a primary determinant of page generation time. A hosting plan on older MySQL versions or a heavily loaded database server will generate pages slower than a plan with current MySQL versions and appropriately provisioned database resources. Look for hosts that specify their MySQL version and offer isolated database resources.
Object caching (Redis or Memcached) significantly reduces database query load for WordPress. Current PHP version support (8.2 or later) improves WordPress execution speed. These are the hosting features worth paying for once storage size is no longer the primary concern.
According to web hosting industry research, the majority of WordPress site owners cite storage and price as their primary hosting selection criteria. After media offloading, storage size becomes irrelevant and the comparison shifts to PHP performance metrics where there are real and measurable differences between providers at the same price point.
The “unlimited storage” marketing will not stop anytime soon because it works. But WordPress site owners who understand what is actually unlimited, and who have moved their media to a purpose-built FTP storage server using WP FTP Media’s shared hosting storage escape plugin, are evaluating hosting on the metrics that actually determine WordPress performance. That is a fundamentally better position to be in when renewing or switching plans.
Stop fighting your host’s unlimited limits. Move the media and the problem disappears.
WP FTP Media transfers your entire WordPress media library to external FTP storage, deletes local copies to free inodes and disk space, and keeps your shared hosting account well under any plan’s real limits permanently regardless of how fast your catalog grows.
Grabbed this after my third "unlimited storage" host suddenly cut me off for "using too much space." Turns out their definition of "unlimited" in the fine print is... creative, to say the least. Never knew inodes could be the real sneaky limit not just the raw gigabytes. this saved me from another shock bill when my media library ballooned. only bummer? i didn't find it before signing my last hosting contract. If you're on shared hosting, do yourself a favor and give it a read.
The guide's right about inodes being the real issue not just storage space. My WooCommerce site hit 180k inodes out of nowhere, and my host suspended me even though they advertise "unlimited" everything.
Hey folks, just wanted to share my experience with this guide since I run a WooCommerce store. the breakdown on why "unlimited storage" isn't really unlimited was super helpful especially the part about how media heavy sites like mine hit those hidden limits way faster