# Vereiste lokale opslag voor afbeeldingen waarnaar wordt verwezen via URL versus geüploade afbeeldingen?

**URL:** https://meta.discourse.org/t/required-local-storage-for-url-referenced-images-vs-uploaded-images/238881
**Category:** Support
**Created:** [13 september 2022 om 15:27 UTC](https://meta.discourse.org/t/required-local-storage-for-url-referenced-images-vs-uploaded-images/238881 "2022-09-13T15:27:32Z")
**Posts on this page:** 3
**Page:** 1

<div class="post-metadata">

### Author: ![Cardinalflyer](https://avatars.discourse-cdn.com/v4/letter/c/f14d63/32.png) [@Cardinalflyer](https://meta.discourse.org/u/Cardinalflyer)
#### Post date: [13 september 2022 om 15:27 UTC](https://meta.discourse.org/t/required-local-storage-for-url-referenced-images-vs-uploaded-images/238881/1 "2022-09-13T15:27:32Z")

</div>

I’m concerned about using up the allotted space for my instance of Discourse. Although we still have substantial headroom, I like to plan ahead. I’ve suggested to my users that referencing images by URL will save us space over uploading those images.

But one user points out that it appears that Discourse uploads a local copy, even from URL referenced images.

Does the system use the same amount of storage either way? If so, asking for URL referencing instead of uploading is adding work with no benefit.

Our Community is about private aircraft. Most images are technical, related to aircraft maintenance. But some users have started sharing multiple images from their recent flights… usually boring shots of random cities from the air that look like every other picture from an airplane.

Understanding how the difference reference methods impact storage will help me guide policy. Or perhaps available storage will magically grow faster than usage? It could happen!

---

<div class="post-metadata">

### Author: ![Falco](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/falco/32/179432_2.png) [@Falco](https://meta.discourse.org/u/Falco)
#### Post date: [13 september 2022 om 15:51 UTC](https://meta.discourse.org/t/required-local-storage-for-url-referenced-images-vs-uploaded-images/238881/2 "2022-09-13T15:51:55Z")

</div>

> [@Cardinalflyer](#):
>
> But one user points out that it appears that Discourse uploads a local copy, even from URL referenced images.

Yes, that is a big Discourse feature to ensure that discussions with images won’t become useless when those hotlinked images stop working in a couple of years.

You can disable it with the site setting `download remote images to local`, but it will result in a worse user experience over time.

> [@Cardinalflyer](#):
>
> Does the system use the same amount of storage either way? If so, asking for URL referencing instead of uploading is adding work with no benefit.

Yes. Exactly.

> [@Cardinalflyer](#):
>
> But some users have started sharing multiple images from their recent flights… usually boring shots of random cities from the air that look like every other picture from an airplane.

We have a quite sophisticated image compression feature that will result on those images taken from smartphones be 50x smaller than what their size would be otherwise.

See [Faster (and smaller) uploads in Discourse with Rust, WebAssembly and MozJPEG | Blog](https://meta.discourse.org/t/faster-and-smaller-uploads-in-discourse-with-rust-webassembly-and-mozjpeg-blog/196998).

Another option is using a dedicated [Using Object Storage for Uploads (S3 & Clones)](https://meta.discourse.org/t/using-object-storage-for-uploads-s3-clones/148916) to store those images, which can scale independently from your forum server storage.

---

<div class="post-metadata">

### Author: ![system](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/system/32/443519_2.png) [@system](https://meta.discourse.org/u/system)
#### Post date: [13 oktober 2022 om 15:52 UTC](https://meta.discourse.org/t/required-local-storage-for-url-referenced-images-vs-uploaded-images/238881/3 "2022-10-13T15:52:00Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.
