Bynder writes that its WordPress plugin works out of the box with the Gutenberg editor. If your pages are built in Elementor, this plugin opens Bynder asset selection there, and writes into WordPress what the visual needs to behave like a WordPress media file.
Dropping a DAM URL into an Elementor widget takes ten seconds and costs a lot: the image loses its srcset, its dimensions and its lightbox, and its alt text stops being tied to the media repository. Not through misconfiguration, but because WordPress indexes its media by record identifier, never by URL.
The asset leaves the DAM, lands in the CMS, and settles into the editor — keeping its identifier.
This is how Bynder describes its own WordPress plugin:
« Out of the box, the WordPress plugin only works with the Gutenberg Editor. The open-source version of the WordPress plugin allows you to make changes to the plugin itself and potentially make it work with other plugins, such as other editors. »
Elementor is another editor. This plugin is the adaptation that sentence points at, and the work sits exactly where you would not expect it: not in the API call, but in what Elementor does with what it is handed.
There is nothing editor-specific about this: several DAM connectors for WordPress state Gutenberg as the supported editor, and point page builders towards an adaptation. It is a characteristic of how these connectors are built, not a shortcoming of any one of them.
In WordPress, a media file is not a file: it is a record. The content type is called “attachment”, the file path lives in the _wp_attached_file meta, and the derivatives generated at upload live in the sizes array of _wp_attachment_metadata. The whole responsive image chain starts there: wp_get_attachment_image_srcset calls wp_get_attachment_image_src, which calls wp_get_attachment_metadata. Every link needs the attachment id, and returns false without it. A DAM, for its part, indexes by its own identifier and serves derivative URLs: the two repositories never meet on their own.
Elementor does not write its content into post_content: it serialises the page’s entire tree as JSON, in the _elementor_data meta. Its media control natively stores the url, id, size triple there — so the slot for an identifier already exists. At render time, Group_Control_Image_Size does not test that identifier alone: it also checks that the requested size is one of the sizes WordPress has registered. With both, Elementor hands over to wp_get_attachment_image and adds the wp-image class followed by the number. With either missing — and the “Custom” size the panel offers is not a registered size — it composes an img tag itself with src, alt and lazy loading, nothing more. The identifier is necessary, not sufficient.
WordPress’s own safety net catches nothing. On a page that goes through the_content, WordPress re-processes the content with wp_filter_content_tags, hooked at priority 12, therefore after Elementor’s insertion at priority 9: the HTML does pass through the net. But that net looks for the identifier inside the wp-image class, by regular expression — precisely the class the no-id branch never writes. The net exists, runs at the right moment, and finds nothing to hook onto. So the question is not which URL to serve, but whether the identifier survives to render.
The dependency does not stop at the Image widget: resolving a size for a section or container background image goes through the same control, and only resolves when an identifier is present.
Each one follows from a constraint set out above, not from a feature list. That is what makes them checkable: if a decision is wrong, the constraint that justifies it is published right above it.
Selection happens inside the editor, through Bynder’s asset picker component, without leaving the page being built. Elementor documents the registration of third-party controls: the picker is a control in its own right, not something bolted onto the native one.
This is the central commitment: wherever the visual has to behave like a WordPress media file, an attachment id exists — and with it the srcset, the registered sizes, alt text tied to the repository, and the lightbox. Where freshness matters more than those guarantees, the referenced mode stays open: that is the trade-off described next.
The trade-off is not settled once and for all. Bynder’s own plugin demonstrates it: it references the asset on an image block, but genuinely downloads the file for the featured image, because WordPress’s featured-image API requires an identifier. The same distinction applies here.
On selection, Bynder returns the full set of available derivative URLs, and documents that its component defaults to the “webimage” derivative for images. Which derivative serves which size is a decision to be made, and it is made once, at configuration time.
Alt text coming from the DAM is written into the meta field WordPress actually queries, not just into the widget setting. The distinction decides what follows: without an attachment id, WordPress looks for alt text nowhere but in the setting itself.
Bynder documents the move from the /m/ format to the /asset/ format as the default returned by its APIs from the week of 30 March 2026, with legacy links still working. A plugin that recognised its own visuals by the shape of their address would have aged that day.
URL rewriting mechanisms designed for WordPress apply to the_content filters. An Elementor page’s content lives elsewhere, as JSON in a meta field: what covers one does not automatically cover the other, and that gets handled explicitly rather than discovered in production.
The decisions above explain why the plugin is built the way it is. Here is what it does once installed.
Dedicated Elementor widgets for image, video and gallery, plus a picker button added to Elementor’s own Image widget and to the WordPress editor’s image block. You choose an asset without switching tools, and the native controls — sizes, caption, link, lightbox, styling — keep working.
WordPress’s media window gains a “from Bynder” tab. The chosen asset becomes a media object the rest of the site can handle — featured image, blocks, other plugins — without the file being copied into the library.
A migration engine moves an existing media library into the DAM and rewrites the site to point at it. Dry run first, batched work you can stop and resume, the original state recorded before every write, and a full rollback. Nothing is deleted.
Activation happens per site, and the entitlements returned are signed then verified locally: a value tampered with in the database invalidates, it never unlocks. If the licence server goes down the site keeps working through a grace period, and updates arrive in WordPress’s usual update screen.
Documented extension points let you adapt the behaviour — which derivative serves which size, which widgets get the button, what a migration includes — from a child theme or your own plugin, so without touching the shipped code and without losing your changes at the next update. Full interface in French and English.
Pasting a URL works: the image shows up. What disappears is less visible. Without an attachment id, Elementor composes a tag with no srcset, no sizes, no width or height, and none of the anchor class WordPress later looks for to complete the HTML. The browser then downloads the same image for a phone and for a wide screen, and is not given, in the tag itself, the dimensions it would need to reserve its space. That is exactly the work this plugin does: keep the identifier, so the complete branch is the one taken.
It depends on the mode chosen for that surface, and that is a decision to make at configuration time rather than discover afterwards. A referenced visual follows its asset; a visual imported into the media library is a copy, and a copy does not update itself. Bynder also documents a cache expiry time on its CDN: even in referenced mode, propagation is not instantaneous.
The question is worth asking before buying, not after. Visuals imported into the media library stay: they are ordinary WordPress attachments. Referenced visuals depend on the DAM URL. That is the main argument for the imported mode on critical surfaces, and the main argument for the referenced mode wherever freshness matters: both are defensible, and the choice is made surface by surface.
It depends on the integration route. Elementor documents the registration of third-party widgets and controls in its base version. Its developer documentation, however, states that “the basic version of Elementor does not support active dynamic tags. They are a feature of Elementor Pro”: an integration relying exclusively on Dynamic Tags would inherit that condition. It is a point to settle against your own installation, and I would rather say so upfront.
No, and the two do not address the same editor. Bynder publishes its plugin and documents that it works with the Gutenberg editor, adaptation to other editors going through its open-source version. If you build your pages with Gutenberg, the vendor’s plugin is the first thing to evaluate. This one addresses sites whose pages are built with Elementor.
This is verified rather than promised. An installation that already has an external media source — another DAM, an offload to object storage — has several plugins sharing the same WordPress and Elementor hook points, and that kind of conflict cannot be inferred from a product page. If that is your situation, say so when trialling: it takes minutes to establish on your own installation, which is a great deal earlier than discovering it in production.
Those served on the public site, yes, and their derivatives with them: Bynder documents that marking an asset public does not make its derivatives public, and that its picker component needs both. This is not a constraint of the plugin, it is the DAM’s delivery model, and it is better checked on your portal beforehand than during.
Tell me how your pages are built and where your visuals live today: the first conversation is for checking that your portal and your installation allow what you need, before any question of terms.
Every technical claim on this page comes from one of these sources, consulted on 30 August 2026. They describe two pieces of software that keep moving: if you are reading this long after that date, check before relying on it.
Bynder, WordPress and Elementor are trademarks of their respective owners. They are used here to name the software the plugin works with: no affiliation or partnership is claimed. Brand pages: Bynder — presse et médias · WordPress — logos · Elementor — logos