Use case
Context quickly exposed here #3502, I'm building terrain-viewer, a pure frontend react app that generates dynamic visuals, and want my users to share a link to socials with a custom OG image that reflects the current state of the app.
Today the flow requires:
- Capture canvas as base64
- Upload to a third-party image host via their respective POST APIs (imgbb, Cloudinary, etc.) to get a public URL
- POST to Dub.co with that image URL to be used as og-media thumbnail metadata
This adds a dependency on an external image hosting service purely as a bridge.
Proposed change
Allow the image field in POST /links to accept either:
- A base64 data URL (
data:image/png;base64,...), or
- A
multipart/form-data upload
Dub.co would store the image internally (even with a short TTL — a few minutes would be sufficient for social crawlers to fetch OG tags) and resolve it to a public URL before the short link is returned.
A short TTL is fine because social platforms (Twitter/X, Facebook, LinkedIn etc) crawl OG images within seconds to minutes of a link being pasted. The image doesn't need to be stored permanently — just long enough for crawlers to fetch it. A 1–24hr TTL would cover virtually all cases.
Benefit & alternatives
This would make Dub.co a complete one-call solution for frontend-only apps that need to share dynamic OG images, removing the need for a separate image hosting dependency entirely.
Imgbb, Cloudinary free tier do work fine but they add API keys, extra fetch calls, and external dependencies to otherwise simple frontend apps.
Use case
Context quickly exposed here #3502, I'm building terrain-viewer, a pure frontend react app that generates dynamic visuals, and want my users to share a link to socials with a custom OG image that reflects the current state of the app.
Today the flow requires:
This adds a dependency on an external image hosting service purely as a bridge.
Proposed change
Allow the
imagefield inPOST /linksto accept either:data:image/png;base64,...), ormultipart/form-datauploadDub.co would store the image internally (even with a short TTL — a few minutes would be sufficient for social crawlers to fetch OG tags) and resolve it to a public URL before the short link is returned.
A short TTL is fine because social platforms (Twitter/X, Facebook, LinkedIn etc) crawl OG images within seconds to minutes of a link being pasted. The image doesn't need to be stored permanently — just long enough for crawlers to fetch it. A 1–24hr TTL would cover virtually all cases.
Benefit & alternatives
This would make Dub.co a complete one-call solution for frontend-only apps that need to share dynamic OG images, removing the need for a separate image hosting dependency entirely.
Imgbb, Cloudinary free tier do work fine but they add API keys, extra fetch calls, and external dependencies to otherwise simple frontend apps.