In a support thread titled “Can I delete the original uploads?”, sedget asks if they can delete original image files after optimized versions are generated, to save disk space. codinghorror suggests optimized images can be deleted since they’re dynamically generated from originals — a claim sam clarifies: while optimized images can be deleted, doing so breaks image display until a full rebake is run, and may require manual table fixes — not recommended. zogstrip adds that “optimized” images are actually thumbnails derived from originals, meaning originals are essential for regeneration. sedget accepts this, noting the 9.8GB total storage for only 3.9GB of originals, and hopes for future features to merge or better manage originals and optimized files. supermathie explains the design trade-off: storing multiple optimized sizes uses more disk space but saves bandwidth and client-side memory, while on-the-fly resizing is too CPU-intensive to be practical. Disk space is considered cheaper and more scalable than computational resources.
hello,
I need space and i want to know if i can delete original in upload dir?
I’m not asking for orphan files I’m asking if original guet an optimized version and so that’s allow me to delete them?
/var/discourse/shared/standalone/uploads/default# du -h --max-depth=1
3.9G ./original
5.9G ./optimized
I think you can delete the optimized, not the original. Because the optimized versions are dynamically created from the originals. Is that correct @sam?
You can delete optimized but images will look broken on all posts till you run a full rebake, you may also have to fiddle with the table
Not recommended
FYI, what we call optimized images are more “optimized thumbnails” than optimized versions of the original images.
Like @sam said, you’ll always need the originals to generate the thumbnails.
Hello, i understood. Now i have to wait for change in originals management like an option to merge originals and optimized to have my directories less fat 
9.8G0 of space for only 3.9 Go originals .
This is a trade-off we have chosen - higher storage space on the server means we can pick the best image to send to the client, saving bandwidth and memory.
Resizing on the fly takes far too much CPU to be viable, whereas disk space is relatively cheap.