You might see that the Dropbox Community team have been busy working on some major updates to the Community itself! So, here is some info on what’s changed, what’s staying the same and what you can expect from the Dropbox Community overall.
Forum Discussion
Force render issues (raw=1) and shared links won't work for hosting.
images were perfect on all browsers until yesterday afternoon - what is the fix or is this a dropbox issue?
We are rolling out a fix for issues with raw=1 and dl=1 links that started recently. Please try again and let us know if it's still not working.
Been using the raw=1 code at the end of Dropbox links to load images to a Wordpress site that has very limited local storage. All of the images uploaded with this link are no longer loading, but images from the web are still working fine.
All my photo links on the geocaching.com site have stopped working when using the /scl/ link.
the old /s/ links still work.
Tried dl=1 and raw=1
Tried on Chrome & Firefox.- Jay
Dropbox Staff
Hi Stratoman, thanks for bringing this to our attention.
Could you try these steps to see if they help with your shared links?
Keep me posted!
Thanks Jay, I've had the same issue, the thing that worked for me is this:
https://dl.dropbox.com/scl/fi/<token>/path.jpg?rlkey=<token>&dl=0- Replacing www with dl works exactly like a ?raw=1 link: this will directly render content for public links in the browser. It requires following an HTTP 302 redirect.
https://dl.dropboxusercontent.com/scl/fi/<token>/path.jpg?rlkey=<token>&dl=0- Works like a ?raw=1 link, but the application or browser will not need to follow an HTTP 302 redirect to access the content.
the other options are not functionning anymore, please what's the reason behind this strange behavior ?
Same issue.
same issue here. when using the "raw=1" link, picture don't show in my obsidian notes, before is working fine.
- Jay
Hi Msloane2, thanks for bringing this to our attention.
Just for clarification, when you say 'images from the web', do you mean when you open the shared link from outside of the Wordpress site?
This will help me to assist further!
It appears that what is being returned for a URL like removed has a Content-type of "text/html" instead of being the raw image data. It appears that the image is eventually delivered, but only after a ton of JS scripts and a 302 redirect.
This is also breaking Google Docs' PDF renderer, which is now displaying the source-text of an HTML page instead of the PDF file itself.
...or at least it was. It's now "refusing to connect."
Same problem here. Directly passing the link into the browser works. Rendering the files as part of another website does not.
Everything uploaded before the new link change renders fine. Every file that has the new link (with the "rlkey=" in the URL) breaks and cannot be rendered. Filetypes (jpg/png/mp3) is exactly the same. The only difference is the URL structure. Happens on any platform I use (gallery platforms with html displays/boxes, google docs and sheets, etc) as well as in any browser I tried with the latest versions and cache cleared (Firefox, Chrome, Opera).
- The Wordpress feature to upload images via link is working fine, as copying an image link from elsewhere on the internet and using that to upload an image is working as normal. It is just the Dropbox links that aren’t.
Copying the link directly from Dropbox and going to the url from outside of Wordpress brings the image up without an issue.- Jay
It sounds like the link itself is working normally in that case. This would be an issue with how Wordpress is processing the image link. Have you tried contacting them directly regarding this matter?
Did you get a fix? All of my iframe embedded videos using the raw=1 change in the link have stopped working on Wordpress too.
No fix yet. All my shared images are still broken today.
Hi
I use images from Dropbox to display images on websites. For this I use the public link such as:
https://www.dropbox.com/scl/fi/5x1t2ddk9wlhxz5naoscg/2204-01.jpeg?rlkey=m8zkxxnzge6s05rqo696m0jq8&raw=1
(ending dl=0 replaced by raw=1).
This no longer works. No image is displayed on the website.If I add the address:
directly into the browser, the adress is redirected to
Why that? I think that the redirect is the reason why the image can no longer be displayed on the website where the image is integrated.
Any idea to solve this issue?Just an FYI this only is affecting files later than June of 2023. All of my prior files will still load with raw=1
FWIW, I'm seeing the broken links with images shared in April. Some older images are still working, but I'm not sure when the cut-off date is yet, if there even is one.
I read elsewhere that the cutoff could be March, but there is no official confirmation from Dropbox about this issue. For now, I'm assuming no images are guaranteed to remain active.
Hopefully, Dropbox can clarify what's going on.
mondstaub wrote:...
If I add the address:
directly into the browser, the adress is redirected to
https://ucd8a1098089b4c4a8845e8a7d2b.dl.dropboxusercontent.com/cd/0/inline/CSR-j0SA5XN8_K8Lvb8wcnZjUS-ET9TqBGZlXDQJjXPcaeqGAHINekXc1mb-tgzx-Sq7g1twcAf32L6TbV-94Jx4q85sxuObdvn4sl6iNuRBjfUrUg6rJLDDOJS4PmZ_ndV2egfdRLNMuQpQgypmrdJ0/fileWhy that? I think that the redirect is the reason why the image can no longer be displayed on the website where the image is integrated.
...Hi mondstaub,
Actually No. Dropbox links have been always redirecting. You probably haven't noticed but any other than preview link has redirected all the time. So described by you is not something new and byself cannot be the reason for observed issue. Despite there is something new and it's about how this redirection happens! While till some time ago it was protocol redirect (HTTP location redirect), recently Dropbox started using page redirect (HTML page redirect itself to another place). This is something problematic in most use cases since while an image is expected text file is received, for instance. Since this is NOT something normal, that confuses most applications (including media players, browsers, etc.). Only few are able to handle HTML redirect. Of course when loaded in the main frame of a browser (not as an image inside page or something else) all web browsers handle such redirection correctly (on such a place would be strange to be something other than HTML, so HTML redirect is possible too). That's why those links work in browsers as a page, but do not it while embedded in any way. That's what the nature of this issue is. Combined with forbidding, forced by Dropbox, of such "pages" to load as inline frame, for instance, makes this issue even more hard. There are still some workarounds (not all link types are changed yet). 😉
Hope this clarifies matter.
iggy097 wrote:Just an FYI this only is affecting files later than June of 2023. All of my prior files will still load with raw=1
Hi iggy097,
Yes and No. There is nothing related to "ages" of your files, but to their links creation time. Old links (created before last "move") would continue work, but all new links (it doesn't matter to old or new files) will follow discussed new behavior (I hope still, it's some mistake that will be fixed). 🤷 That's it. In other words, this change is not retroactive for links.
Good luck to all of us.
