WordPress: where the images end up, for someone who has to run one

This page is written for somebody who has to run a site, not somebody who wants to build one. It names the controls, says where they live, and says what goes wrong at each of them. The mechanics underneath, the request arriving, the template being chosen and the database being queried, are set out separately in How it actually works.

The 2 things both called WordPress

The 2 things called WordPress are a hosted service and a piece of software you install yourself, and confusing them is the single most common reason a tutorial does not match the screen in front of you. WordPress.com is the hosted service: an account is created, a server is run for you, and updates happen without you. WordPress.org is where the software itself is downloaded, to be installed on hosting you rent, at a host such as Bluehost or any other provider that runs PHP and a MySQL or MariaDB database. Both produce a site whose admin area sits at /wp-admin/ and looks broadly the same, which is exactly why the difference stays invisible until it bites.

Decide this first, because it is the decision that is expensive to reverse. A hosted site can be exported and moved to a self-hosted install, but the plugins you could not install were also the plugins you never designed around, so the move is rarely a straight swap.

What a theme is, and what a plugin is

A theme controls how the site looks and a plugin adds something the site does, and keeping that line clean is the difference between a site you can redesign and a site you cannot. A theme is a folder in wp-content/themes/ containing templates and a stylesheet. Classic themes are built from PHP template files plus style.css. Block themes are built from HTML templates in a templates/ folder plus a theme.json file that declares colours, spacing and typography in one place. Change the theme and the design changes; the posts do not move.

A plugin is a folder in wp-content/plugins/ holding at least one PHP file with a plugin header, which attaches itself to the software using hooks such as add_action and add_filter. Contact forms, backups, caching, custom fields and search engine metadata are all plugin work. Advanced Custom Fields, usually shortened to ACF, is the common example: it adds structured fields to a post type and stores their values as post metadata.

Page builders such as Elementor, Divi and Avada sit awkwardly between the 2 categories. They install as plugins or themes, then replace the built in editor with their own canvas, their own layout controls and their own storage format. That is why a Divi tutorial or an Elementor tutorial teaches almost nothing transferable: you are learning that product, not WordPress. It is a real choice with a real cost, and it belongs in the list of early decisions rather than in month 4.

Where your content actually lives

Your content lives in 2 separate places, and only one of them is a folder you can look at. The words are rows in the database. A post or a page is a row in the wp_posts table, its extra fields are rows in wp_postmeta, site settings are rows in wp_options, and accounts are rows in wp_users. The wp_ prefix is set once during installation by $table_prefix in wp-config.php, so on some installs those table names carry a different prefix.

Uploaded files live on disk. Every image, PDF and video you upload is written into wp-content/uploads/ inside a folder for the year and a folder for the month, and the database keeps a row that points at the file. That split has 2 practical consequences worth memorising:

• Back up both. A database dump alone restores your text and loses every image. A copy of wp-content alone restores your images and loses every word.
• Move both together. Copying files to a new host without the database gives you a site with no posts, which is the classic failed migration.
• Search the database, not the folder, when a phrase has gone missing. There is no file on the server containing the text of your article.

The 3 decisions that matter early

These 3 decisions matter early because each one is cheap now and expensive later, and none of them is about design.

1. Choose hosted or self-hosted before you publish anything, using the table above rather than a price comparison.
2. Set your permalink structure once, under Settings > Permalinks, and then leave it. Changing it after publication changes every URL on the site, and every link anyone made to you stops working unless you add redirects by hand.
3. Decide whether a page builder owns your layouts. Build 200 pages in a builder and the builder is now a permanent dependency, because its markup lives inside your content.

A fourth setting is worth 30 seconds while you are in there. Site language is set under Settings > General, and it changes the admin interface, not just the front of the site. Set it to Hindi, Tamil or any other translated language and the dashboard menus are renamed to match, which matters more than the language a tutorial happens to be spoken in.

Which WordPress tutorial to trust

Trust a WordPress tutorial that shows a dated screenshot of the screen you are actually looking at, and close the ones that do not. The editor has changed shape once in a major way: content is now assembled from blocks, while older material shows a single large text box, which is the classic editor. That one visual difference dates a tutorial faster than any publication date on it.

• Prefer the software's own documentation and its free lesson library for anything about the core screens, because it is revised alongside the releases.
• Use video for the question "where is that control", which is what video is genuinely good at, and distrust it for anything involving a version number.
• Treat a downloaded PDF as the format most likely to be stale, since nothing about it updates when the interface moves.
• Read host branded guides, such as a Bluehost walkthrough, as documentation for that host's control panel rather than for WordPress.
• Ignore the year in the title. "2025" or "2026" in a headline is a marketing habit, not a claim about the software.

Developers get a different path. Install locally first, using a local server tool on your own machine so that the site runs at localhost with no hosting bill and no visitors, set WP_DEBUG to true in wp-config.php so errors are visible instead of silent, and start with a child theme so your edits survive an update of the parent. From there the whole customisation surface is 2 functions, add_action and add_filter, plus knowing which hook fires when.

What breaks first

What breaks first is almost always a plugin, and the fix is usually a rename rather than a reinstall. A blank white page after an update means PHP stopped with an error; connect over SFTP, rename the offending folder inside wp-content/plugins/, and the site returns with that plugin deactivated. Locked out of /wp-admin/ is the same procedure applied to wp-content/themes/. Keep the number of active plugins small enough that you can name all of them, because each one is code running on every request.

The second thing that breaks is images, and it breaks quietly. Uploading a 6000 pixel wide file straight from a camera makes WordPress generate several resized copies, fills wp-content/uploads/, and slows every page that shows it. Resize and compress in an image editor before the upload, not after. The editing itself belongs there too: Changing one colour in a photo is the ordinary example, and it is work done on the file before it ever reaches the media library, because what WordPress stores is the result rather than the recipe.

Where to go next

WORDPRESSHow WordPress actually works, from the request to the image on the pagePHOTOSHOPChanging one colour in a photoHow to change one colour in a photo