WordPress ships with a Gallery block built into the editor. It is free, it is already there, and for a casual blog post it may genuinely be all you need — which makes “do I need a gallery plugin at all?” a fair first question before you install anything. The answer depends entirely on what you are trying to do, and the native block has a clear ceiling. Knowing where that ceiling is means you neither add a plugin you do not need nor fight a block that cannot do the job.
This sits alongside the page-builder gallery comparison under our best gallery plugins guide.
What the native Gallery block does
The block editor’s Gallery block is more capable than it once was. You can upload and drag-drop images, reorder them, set the number of columns, choose to crop to a uniform size or keep proportions, and link images (including to their media file, which some themes turn into a basic lightbox). For dropping a handful of photos into a blog post in a tidy grid, it does the job cleanly, with zero extra plugins and full integration with the editor you are already using. For that casual use case, reaching for a plugin would be over-engineering.
What it can’t do
The ceiling arrives quickly once you want more than a static grid. The native block has no advanced layouts (no true justified or mosaic, limited masonry), no filtering or search, no real control over thumbnail sizing beyond columns, no built-in sophisticated or accessible lightbox (you are at the mercy of whether your theme adds one), and — importantly — no way to reuse a gallery. Each Gallery block lives in the one post or page where you built it; if you want the same gallery in two places, you rebuild it. There is also no proofing, no e-commerce, no watermarking, none of the photographer or shop features. The block is a display element, not a gallery system.
Two practical frustrations show up with real use. Reordering becomes clunky once a gallery has many images — dragging image forty into position three is tedious. And high-resolution images can slow the page, because the block’s handling of sizing is basic and you are relying on WordPress core’s defaults rather than gallery-aware optimisation. Neither is a dealbreaker for a small gallery; both bite at scale.
Do this now. Decide honestly which camp your gallery is in. Is it “a few photos in a blog post, in a grid, that I will never reuse”? The native block is the right, no-overhead choice — use it. Is it “a real gallery I will reorder, reuse, want a good lightbox for, maybe filter, and keep adding to”? You have described the block’s ceiling, and a plugin will save you fighting it. Naming the use case prevents both over-engineering and under-tooling.
The performance reality
A nuance on speed: WordPress core has improved here. Since version 6.3 it skips lazy-loading the first images and adds fetchpriority to the likely main image, so a native-block gallery is not automatically a performance disaster the way it might have been years ago. But the block does not give you gallery-aware control — you cannot easily ensure the first row loads eagerly while the rest lazy-loads, or that each image is served at an ideal size for its display slot. For a small gallery the core defaults are fine; for a large or image-heavy one, the lack of fine control is where a gallery-aware plugin pulls ahead (see the gallery page speed guide).
Who the native block is fine for
Be generous about this, because the block deserves it: casual bloggers, content sites, and anyone whose galleries are small, static, and post-bound. If you add a few photos to articles now and then and want them in a neat grid, the native block is the correct tool and a plugin would be needless weight. The whole point of knowing the ceiling is to use the simplest tool that clears your bar — and for a lot of sites, the native block clears it.
The upgrade path
When you do outgrow it, the move is straightforward, and a good gallery plugin makes the transition gentle because it also works in the block editor — you place its gallery block where you would have placed the native one, gaining the layouts, lightbox, reuse, and performance control without leaving Gutenberg. FotoGrids works this way: a Gutenberg block (and Elementor, Divi, and Bricks widgets) with six free layouts, the immersive lightbox, and proper responsive sizing, plus galleries you build once and reuse anywhere. The native block is a fine starting point; the upgrade, when you need it, is a block swap rather than a rebuild of how you work.
Key takeaways
- The native Gallery block is genuinely fine for small, static, post-bound galleries — no plugin needed.
- Its ceiling: no advanced layouts, filtering, real lightbox, reuse, proofing, or e-commerce.
- WordPress 6.3+ helps gallery speed, but the block lacks gallery-aware sizing control.
- Outgrowing it is a block swap, not a rebuild, if your plugin also works in Gutenberg.
Is the native WordPress Gallery block good enough?
For small, static galleries in a blog post — yes, and a plugin would be over-engineering. It handles upload, reorder, columns, and basic cropping cleanly with no extra plugin. It falls short when you need advanced layouts, filtering, a good or accessible lightbox, gallery reuse across pages, proofing, or e-commerce.
What can’t the WordPress Gallery block do?
No advanced layouts (true justified or mosaic), no filtering or search, no built-in sophisticated or accessible lightbox, no fine thumbnail-size control, and no gallery reuse — each block lives only in the post where you built it. It also has no proofing, watermarking, or e-commerce features. It is a display element, not a gallery system.
Will the native gallery block slow my site?
Not as much as it once might have. WordPress 6.3+ skips lazy-loading the first images and prioritises the likely main image. But the block lacks gallery-aware control over sizing and loading, so for large or high-resolution galleries a gallery-aware plugin handles performance better. For small galleries, the core defaults are fine.