How to Enlarge an Image in WordPress With the Native Lightbox

First, decide what “bigger” means

There are two separate levers here. The first is the size of the image displayed in the post. The second is the size of the file available when someone opens it. A lightbox changes the viewing experience, but it cannot invent detail that was never uploaded.

In the editor, an Image or Gallery block may offer resolutions such as Thumbnail, Medium, Large, and Full Size. The exact choices depend on the original upload and what the theme supports. Selecting Large can make the image look better in the page layout. Selecting Full Size can give the lightbox a bigger source to show.

If the original file is only 300 pixels wide, choosing Full Size will still produce a 300-pixel image. There is no crispness switch hiding in the toolbar. For a deeper explanation of registered sizes, see WPShout’s guide to custom WordPress image sizes. To inspect whether a page points to the original file or a generated derivative, use the full-sized image URL method.

Quick rule: choose a sensible display resolution, then make sure the source file is large enough for the detail visitors actually need.

What the native lightbox does

The native lightbox expands a supported image over the current page when a visitor clicks it. The feature arrived with WordPress 6.4 for the core Image block, and the developer handbook documents the related theme.json settings. ^[1] Learn WordPress introduced the same release as a way to enable lightbox behavior globally or for individual images. ^[2]

That does not mean every WordPress site has identical controls. A block theme can enable lightbox behavior globally and let editors change it per image, or it can hide that editing control. A classic theme can expose a different interface. Plugins and custom blocks can also change what appears in the editor.

The useful mental model is simple: native support is a core-block feature, not a guarantee that every image on every template becomes a lightbox. Start by identifying which block contains the image.

Enlarge one image on click

For a normal core Image block, the current path is short:

• Select the Image block in the editor.
• In the block toolbar, open the Link control.
• Choose Enlarge on click.

The Image block documentation describes this option as opening a larger view without sending the visitor away from the page. It also places the image file and attachment-page choices in the same Link menu, so do not confuse a media-file link with a lightbox. ^[3]

If the control is missing, check the selected block first. Then check the WordPress version and theme settings. A linked image that opens a bare file in the browser is working differently, even if the file itself is the largest available version.

Give a Gallery its own lightbox navigation

A Gallery block has a slightly different selection problem. Select the parent Gallery block, not just one image inside it. Open the Gallery’s Link control and choose Enlarge on click. The current Gallery block documentation confirms that visitors can then move through the gallery images in the larger view. ^[4]

Once the lightbox is enabled, the sidebar may show Navigation button type. Choose Icon for a compact interface, Text for explicit labels, or Both for the clearest compromise. The setting controls the previous, next, and close controls in the lightbox. It is a current Gallery feature, so older WordPress installations may show fewer options.

For gallery creation itself, use WPShout’s guide to creating a WordPress gallery. This refresh stays focused on what happens after the Gallery block is already on the page.

Why the control may not appear

The developer-facing global setting lives under settings.blocks.core/image.lightbox. A theme can set enabled to true for site-wide behavior, while allowEditing controls whether editors can change the option on individual blocks. That is useful context when a site has a block editor but the expected toolbar choice is missing.

Version differences matter too. WordPress 6.4 introduced the Image lightbox, but later WordPress releases and documentation updates added or clarified Gallery controls. Do not promise a current screenshot’s navigation settings to a site that has stayed on an older 6.4 installation. Update WordPress in a staging copy, check the theme’s block settings, and then test the exact content block.

There is also a structural boundary. The native Image control does not automatically extend to a theme’s Post Featured Image block. A Gutenberg issue records that the Image block has lightbox support while Post Featured Image does not. ^[5] Featured images, Classic Editor content, shortcodes, page builders, and custom image blocks may therefore need their own documented feature or a separately evaluated plugin.

Test the experience before calling it done

A lightbox is an interaction, not just a larger JPEG. Add useful alt text when the image conveys information, and leave it empty when the image is genuinely decorative. Keep the trigger visibly discoverable, then test it with a keyboard, a touch screen, and a narrow viewport. Check that focus is understandable, the close control is reachable, and the page remains usable when the image is dismissed.

The Learn WordPress demonstration closes the lightbox with Escape or by clicking outside the image. Treat that as behavior to verify on the target site, not as a substitute for testing. A separate open Gutenberg accessibility issue also documents a case where the server-rendered trigger has no accessible name before JavaScript hydrates, or when JavaScript is disabled. ^[6] A quick accessibility scan can miss that timing window.

• Open the image with a keyboard and confirm the trigger is visible and understandable.
• Use a screen reader or accessibility checker to inspect the button name and dialog behavior.
• Test mobile, slow loading, and a temporary JavaScript-disabled state.
• Confirm captions, alt text, and the surrounding page remain readable after the overlay closes.

Common gotchas during testing

If the image opens but looks no larger, inspect the selected resolution and the original file dimensions. The overlay can be working perfectly while displaying a small upload. If the image works in the editor but not on the front end, clear the page cache and test the published template, then check whether a performance or gallery plugin rewrites the block markup.

Gallery navigation deserves its own check. Open the first image, move forward and backward, and close the overlay from both a pointer and a keyboard. On a phone, confirm that the previous and next controls are not hidden behind browser chrome or squeezed against the image. If a theme changes the button colors or removes visible labels, compare Icon, Text, and Both before choosing the most readable option.

Finally, test a page with several images and a page with only one. A behavior that feels obvious in a three-image gallery can become ambiguous when there is no next item. Record the WordPress version, theme, and block type when reporting a defect. “The lightbox is broken” is much less useful than “core Gallery block on version X, with a custom theme, loses its close label after hydration.”

These checks improve the odds of a solid experience. They do not justify a claim of perfect accessibility, especially when a theme, plugin, or custom block changes the generated markup.

A practical checklist

• Use a large enough original file. A lightbox cannot restore detail lost during upload.
• Choose the Image block’s Link control, then Enlarge on click, for one image.
• Select the parent Gallery block before enabling its lightbox and navigation.
• Choose Icon, Text, or Both after checking which controls the site’s WordPress version exposes.
• Check the theme’s global Image lightbox setting if the editor control is missing.
• Keep Featured Image, Classic Editor, builder, shortcode, and custom-block cases separate.
• Test keyboard, focus, mobile, close behavior, and the no-JavaScript or pre-hydration state.

If the site uses supported core Image or Gallery blocks on a current enough WordPress version, the native lightbox is the sensible first stop. It keeps the visitor on the page and avoids adding another dependency for a small interaction. If the content lives in a Featured Image block, a builder, a shortcode, or a custom block, identify that boundary before copying the core steps. That is where a separately revalidated solution may still be necessary.

That is the update: fix the pixels first, enable the native control second, and verify the actual block and theme before promising a lightbox.