--- title: How to replace an image in WordPress without breaking links description: Re-uploading gives a new URL every time. How to replace an image in WordPress at the same URL with FTP, and the cache and thumbnail fights that starts. pubDate: 2026-08-08 source: https://wpproadmin.com/guides/replace-image-wordpress-same-url/ --- Upload a new photo to replace the one on your homepage, and WordPress does something unhelpful: it keeps the old file exactly where it was and gives the new one an address of its own. You now have two images at two URLs, and every page, template, and email that pointed at the original keeps pointing at it — untouched. If you're looking for how to replace an image in WordPress at the same URL, this is why the obvious method doesn't do that, and what actually does. ## Why re-uploading never gives you the same URL The media library will not overwrite a file. Upload `team-photo.jpg` a second time and WordPress checks the uploads folder, finds a file already using that name, and silently renames the new one — `team-photo-1.jpg`, then `-2.jpg` on the next attempt, and so on. It never asks. It never warns you the name was taken. It just picks a filename that doesn't collide and creates a brand new attachment pointing at it. That's correct behavior for what the media library is protecting against — two unrelated uploads that happen to share a name shouldn't clobber each other — but it means "upload a replacement" and "replace the image" are not the same action. The first always produces a new URL. Only the second keeps the old one. ## What still points at the old file This is the part that makes a new URL a real problem rather than a minor annoyance. Nothing about uploading a replacement touches anything that already references the original: - **Post and page content.** Depending on how the image was inserted, the block or the raw HTML can store the exact URL string, not a pointer to "whichever file is currently in this slot." Swap the file in the library and the old URL keeps rendering wherever it was pasted in. - **Page builders.** Elementor, Divi, and similar tools often save the image URL inside serialized or JSON layout data rather than through a clean attachment reference. Even if you update the "featured image" field, a URL buried three levels into a builder's saved layout won't move. - **Emails already sent.** A newsletter or transactional email that went out with the old image URL embedded in its HTML can't be edited after delivery. Whatever was live at send time is what recipients see, forever, unless you keep serving something at that exact address. - **Everything outside your site.** Backlinks, social media posts that embedded the image, other sites hotlinking it, search engine image results — none of it knows or cares that you uploaded a new file elsewhere. The only way to update all of those at once, without hunting down every place the URL is stored, is to make the same URL start serving different bytes. ## The manual method: replace the file at the same URL To keep the URL, you have to bypass the media library entirely and overwrite the file where it physically lives — by FTP, SFTP, or your host's file manager, not through Add Media. Find the original file in `/wp-content/uploads/`, and upload your replacement with the identical filename, overwriting it in place. The one hard constraint: the extension has to match. A `.jpg` can only replace a `.jpg`. Upload a `.png` or `.webp` under a different extension and you've changed the path, which is exactly what this method exists to avoid — at that point you're back to a new URL, just one you chose by hand instead of one WordPress generated. Do that and the URL genuinely doesn't change. Every place listed above that "still points at the old file" now points at the new one too, automatically, because the address never moved. It also starts two fights you need to plan for. **The cache fight.** Same URL means every cache along the way — the visitor's browser, a CDN, a host-level page cache — treats the file as unchanged and keeps serving the version it already has. There's no built-in signal telling a cache "the bytes at this URL are different now"; that's the entire point of the URL staying the same. You'll need to purge the CDN and any server-side cache by hand, and accept that some visitors' browsers will keep showing the old image until their own cache expires on its own. The usual workaround is a versioned query string — changing the image's reference from `team-photo.jpg` to `team-photo.jpg?v=2` forces browsers and most CDNs to treat it as a different request and fetch fresh bytes, since the query string is part of what gets cached against. It has a real catch, though: the query string only busts the cache everywhere you go back and edit the reference to include it, which means touching every post, template, and page builder layout that links the image — the exact hunt you were trying to avoid by keeping the URL the same in the first place. And some CDNs ignore query strings entirely unless you've explicitly configured them to include the string in the cache key, so it isn't guaranteed to work without checking your CDN's settings first. **The thumbnail fight.** WordPress generates every registered image size — thumbnail, medium, large, whatever `srcset` sizes your theme adds — once, at the moment of upload, and saves each as its own file: `team-photo-150x150.jpg`, `team-photo-300x200.jpg`, sitting alongside the original in the same folder. Overwriting the full-size original over FTP does nothing to those files. They still hold the old image, under their own filenames, and anywhere your theme renders a thumbnail or a responsive `srcset` — which is most places an image actually appears — visitors keep seeing the old picture. You have to regenerate thumbnails afterward, either with WP-CLI (`wp media regenerate`) or a regeneration plugin, so every size gets rebuilt from the file you just dropped in. ## The year/month folder wrinkle Uploads don't all live in one flat folder. By default WordPress files them under `/wp-content/uploads/` by the year and month they were uploaded — `2024/03/team-photo.jpg`, not `2026/08/team-photo.jpg`, if that's when it originally went up. Overwrite the wrong month's copy and nothing changes on the live site, because the URL your pages actually reference is the one from the original upload date, not today's. Before you connect over FTP, find the real path — open the image in the media library and check its file URL, which spells out the year/month folder it lives in. (A small number of sites have the "organize uploads into month- and year-based folders" setting turned off, in which case everything sits directly under `/uploads/` and this doesn't apply — but that's the exception, not the default.) If the page carrying that image was built by duplicating another one, both copies usually share the same featured image file rather than each holding their own — see our guide on [duplicating a page in WordPress](/guides/duplicate-page-wordpress/) for what gets copied and what doesn't. Replace the file once and both pages update, since they were never two files to begin with. ## A plugin already does this: Enable Media Replace You don't have to do any of this by FTP. Enable Media Replace, installed on 600,000+ sites, adds a "Replace Media" option directly in the media library — pick the file, upload the new version, and it handles the overwrite (and, per its own description, the regeneration of thumbnail sizes) without you touching an FTP client. It's a mature, widely used plugin built specifically for this problem, and worth knowing about if you'd rather not manage file paths and image sizes by hand. ## The shortcut Replace Media is one of the content tools in WP Pro Admin, shipping in version 2.2.0. Pick a file in the media library, upload its replacement, and the URL doesn't move — no FTP client, no hunting for the right year/month folder, no separate regeneration step. Every size gets rebuilt from the new file automatically. It also covers the one thing a straight FTP overwrite can't: getting it wrong. The old file is kept for thirty days after a replacement, so a mistaken swap — the wrong image, a lower-resolution version by accident — is a rollback, not a re-upload from a backup. That matters most on a page that's already live and getting traffic, the same caution behind our guide on [editing a published page without unpublishing it](/guides/edit-published-page-without-unpublishing/). WP Pro Admin is a [free download](/), GPL, and it will never show you an ad, an upgrade nag, or a promotional notice — a promise enforced by [a test in the build](/no-ads/), not by a paragraph on a website.