How to Replace Images and Media Files in WordPress

First, decide what should change

Ask one question: is the image wrong in one editor block, or is the underlying attachment wrong wherever it is used?

• One block-editor post or page: replace the selected Image block. Other blocks that use the old attachment can remain unchanged.
• The same Media Library attachment in many places: replace the attachment itself, then check each important reference.

The distinction matters because an Image block stores its own content settings. The WordPress Image block documentation describes the editor controls for that block. ^[1] The core Image block reference describes its block-level behavior. ^[2] Neither is a promise that changing one block rewrites every use of an attachment.

If the request is “change this hero image on this page,” use the first path. If it is “the old logo is wrong everywhere,” prepare for the second path and a wider verification pass.

Replace one image in one Image block

For a normal Image block, the native path is short:

1. Select the Image block in the post or page editor.
2. Choose Replace in the block toolbar.
3. Choose Open Media Library to select an existing item, or Upload to add a new file.
4. Reset returns the block to its initial image-selection state. It is not a replacement method.

Open Media Library points this block at an attachment that already exists. Upload adds the new file to the Media Library and points this block at that attachment. Uploading a separate file is often the safer choice when the new image belongs on this page only, because blocks using the old attachment can keep it.

Save or update the post, then check the published page. This changes the image reference in that selected block. It does not globally replace the Media Library attachment, rewrite unrelated posts, or repair a logo embedded in a template, custom field, or page builder.

Check the block’s alt text after the swap. A new image may need different wording, and changing alt text here is a page-specific edit. Attachment metadata elsewhere can still contain its old title, caption, or description.

If the replacement is a larger or smaller file, inspect the block’s selected resolution too. Publish the page, open the image in a fresh window, and compare the delivered filename and dimensions with what the editor shows. The editor preview alone is not a delivery test.

Replace a shared Media Library attachment

When the existing attachment itself must change, open Media and Library, select the attachment, open Edit Media, and choose Replace Media. Upload the new file, select a replacement mode, and verify the result in the places that matter.

Before the upload, record the attachment ID or Edit Media URL, current file URL, file type, and dimensions. Compare the preview with one known placement on the site. This small identity check matters because replacing the wrong shared attachment is much harder to unwind than swapping the wrong block.

The current Enable Media Replace listing presents two choices. Just replace the file keeps the attachment name and requires the same file type. Replace the file, use the new file name, and update all links uses the new name and file type, and the plugin says it updates links pointing to the current file. ^[3]

Use the first mode when the current attachment name must remain and the replacement has the same file type. Use the second when the new name or type is intentional and WordPress-managed links should follow it. If anything outside WordPress depends on the old URL, map that dependency before choosing either mode.

Read “all links” narrowly. It does not promise to update an external website, an email already sent, a PDF, CSS that contains a URL, an arbitrary custom field, a builder’s private data, a block binding, or a separate copy on an image CDN. If preserving the old filename or URL is the requirement, test that use case before choosing the mode.

Before clicking the final replacement button, make a backup or staging snapshot. The original file is not a safety copy that the plugin will restore for you. Keep an independent copy if rollback matters. ^[4]

Protect metadata, thumbnails, and responsive sizes

Replacing the bytes does not mean every surrounding field is correct. Open the attachment details and check the title, alt text, caption, description, and any other metadata the site relies on. WordPress’s Edit Media documentation lists the attachment fields editors can change. ^[5] The page and post settings sidebar documentation distinguishes the document settings from the settings for the selected block. ^[6]

Then inspect the generated sizes. You can retrieve stored attachment metadata, including image size information, with wp_get_attachment_metadata(). ^[7] WordPress creates image sub-sizes through wp_generate_attachment_metadata(). ^[8] The practical takeaway is simple: check thumbnails, responsive images, and any desktop or mobile layout that uses a different derivative.

A block can also carry its own alt text or size choice. That is why one page can look right while another still shows an old crop, an old caption, or a different source URL. Check the attachment and the rendered block, not just the Media Library preview.

For a shared logo or product screenshot, make a short list of known placements before you replace anything. Include headers, footers, reusable patterns, widgets, feeds, and downloadable documents when those are part of the asset’s job. A replacement is complete only when the references that matter to the site owner have been checked.

If the new image appears unchanged, clear the browser cache, page cache, host cache, image-CDN cache, and any external edge cache in the delivery path. A stale response can hide a correct replacement. WPShout’s caching explainer is useful context if the cache layers are unclear.

Verify the replacement before calling it done

Start with the original request, then test the boundaries around it:

• Open the published page in a private window and confirm the new pixels, filename or URL behavior, alt text, caption, and link destination.
• Check desktop and mobile layouts, including an image that uses a thumbnail or responsive source.
• Search the site for the old attachment or URL if the replacement was meant to be global.
• Open important posts, templates, menus, custom fields, builder layouts, feeds, and downloads that may reference the image differently.
• Clear the relevant caches, then test again from a second browser or network.

The troubleshooting guidance from Enable Media Replace’s support documentation is a reminder to check cached delivery, file permissions, and generated image sizes when the visible result does not match the upload. ^[9] Treat that as a checklist, not a promise that one diagnosis fits every site.

Finally, test the rollback path. Confirm that the independent copy can actually be retrieved before closing the task, especially when the old asset may be needed later.

A practical replacement checklist

• One block only? Use Image block > Replace > Open Media Library or Upload.
• Shared attachment? Use Media Library > Edit Media > Replace Media.
• Need the old name or type? Test the same-file-type mode first.
• Need a new name? Confirm which WordPress-managed links can be updated, and list everything outside that promise.
• Back up or snapshot before replacement, because the original is not automatically preserved.
• Recheck metadata, thumbnails, responsive output, desktop, mobile, and every important reference.
• Purge cache layers and verify from a fresh browser or network.

For a single image in a supported Image block, the native Replace control is the cleanest answer. For a shared attachment, Enable Media Replace can be useful when its filename and link-update trade-offs match the use case. Neither path is a universal “replace this picture everywhere” button. Choose the scope, preserve a rollback copy, and verify the real references.