If you already run Elementor, Divi, or Bricks, you already have a gallery widget — so a reasonable question is whether you need a dedicated gallery plugin at all. The honest answer is “sometimes,” and knowing which time is which saves you both from bolting on a plugin you do not need and from struggling with a widget that cannot do the job. Page-builder gallery widgets are good at simple galleries and hit clear limits beyond that; this is where the line falls.
It is a focused comparison within our best gallery plugins guide, and pairs with the native block vs plugin question.
What page-builder gallery widgets do well
The case for using the widget you already have is real. It is tightly integrated with your builder, so the gallery inherits your site’s styling and you edit it in the same interface as everything else — no new tool to learn. It adds no extra plugin, which is genuinely valuable: every plugin is maintenance, a potential conflict, and a slice of attack surface (see the stack consolidation argument). And modern builder widgets handle the basics competently — a grid or simple masonry, a lightbox, lazy-loading. For a straightforward gallery in a page you are already building in Elementor, the widget is often the right, low-overhead choice. Do not add a plugin to do something your builder already does well.
Where they fall short
The widgets hit limits as soon as the gallery needs to be more than a display grid. The common gaps: filtering and search (browsing a large gallery by tag or category), advanced layouts (true justified, mosaic), sophisticated or accessible lightboxes, client proofing, e-commerce product galleries, and reusing one gallery across multiple pages without rebuilding it. When you need any of those, the builder widget cannot do it and you end up adding a third-party addon or a dedicated plugin anyway — at which point you are running extra code regardless, so you may as well run the tool built for the job.
A documented Elementor gotcha
One specific, well-documented issue worth knowing if you use Elementor’s gallery: the gallery control has been reported to use the original full-size image URLs for thumbnails rather than appropriately sized versions (a long-standing item in Elementor’s issue tracker). The practical effect is that a gallery of high-resolution images can load far more data than it should — your “thumbnails” are secretly full-size files — which hurts page speed badly on an image-heavy gallery. It is the kind of thing that does not show in the editor but quietly tanks your Core Web Vitals. If you build a large gallery with Elementor’s widget, check the actual sizes being loaded in your browser’s Network tab; you may find this is happening.
Do this now. If you have a gallery built with your page-builder’s widget, open it and check two things in the browser Network tab: are the thumbnails loading at thumbnail size or full size (the Elementor gotcha), and is the total image weight reasonable? Then list what the gallery cannot do that you wish it could — filtering, a better lightbox, reuse elsewhere. Those two checks tell you whether the widget is fine or whether you have outgrown it.
“Use the widget until you outgrow it”
The sensible rule is not “always use a plugin” or “always use the builder” — it is a threshold. Use the builder widget while your needs are simple: a styled grid or basic masonry, a standard lightbox, in a page you are building anyway. Reach for a dedicated plugin when you cross into the gaps above: you need filtering, advanced layouts, proofing, product galleries, accessibility you can rely on, or you are managing enough galleries that rebuilding them in the builder each time is a chore. The threshold is when the gallery becomes a thing you manage rather than a one-off element you place. Below the threshold, the widget wins on simplicity; above it, the plugin wins on capability.
When a dedicated plugin wins
Concretely, choose a dedicated gallery plugin when: you have many galleries to manage centrally (not rebuild per page), you need layouts or a lightbox the widget lacks, you need proofing or WooCommerce galleries, performance matters enough that you want a tool that guarantees correct sizing and lazy-loading (avoiding the Elementor thumbnail gotcha), or you want one gallery reusable across pages and even across page builders. A well-built gallery plugin also typically works inside your page builder via its own widget or block, so you do not lose the builder integration — you get the builder’s layout convenience and the plugin’s gallery capability together. FotoGrids, for instance, provides blocks and widgets for Gutenberg, Elementor, Divi, and Bricks, so a gallery you build once renders in whichever builder the page uses, with the performance fundamentals (responsive sizing, correct lazy-loading) handled rather than left to the builder.
Key takeaways
- Page-builder gallery widgets are great for simple galleries and add no extra plugin.
- They fall short on filtering, advanced layouts, proofing, e-commerce, and reuse.
- Elementor’s gallery has a documented full-size-thumbnail issue that can tank gallery speed — check your Network tab.
- Use the widget until you outgrow it; a dedicated plugin that runs inside your builder gives you both.
Do I need a gallery plugin if I have Elementor?
Not for simple galleries — Elementor’s gallery widget handles a basic grid, masonry, and lightbox without an extra plugin. You need a dedicated plugin when you outgrow the widget: filtering, advanced layouts, proofing, WooCommerce product galleries, reliable accessibility, or reusing one gallery across pages. A good gallery plugin runs inside Elementor too, so you keep the builder integration.
Is Elementor’s gallery widget bad for performance?
It can be. There is a documented issue where Elementor’s gallery control uses original full-size image URLs for thumbnails, so a gallery of high-resolution images loads far more data than it should — hurting page speed badly. It does not show in the editor. Check the actual image sizes loading in your browser’s Network tab on any large Elementor gallery.