Would it be smaller or faster to store all images as Base64 encoded text in a database rather than linking out to a .jpg file?
Simple answer from me, NO. Simply too much mysql storage which is far more expensive than server space. Secondly unless well normalised, the table size could negatively impact on performance.
3 Likes
Just to chime in here, we had the same dilemma. We did some testing internally and for us, it was best to do Base64. We didn’t see any type of impact on server performance. For others it may be different. Our purpose was for our customer to upload images to document receiving products at warehouses. The images are not that large, about 2-5 MB in size. You may get different results if your images are larger. By the way, we use MS SQL Server.
If you have your own infrastructure it is potentially feasible,for most users on here they are probably limited to the fairly standard 100mb mysql server limit from hosts so storing images is not feasible
Just to ask from a different standpoint, if I had a 200k image as .jpg and that would be the equivalent of lets say 300 000 characters if Base64 encoded, would those 300 000 characters still take the same 200k of download? Sorry if this is a moronic question, just never really considered this till now.
That’s a good point. Yes, we own and operate our own infrastructure.
I’m not sure, but I believe it would be because you are basically re-building that image in the browser.
1 Like
I guess base64 encoded are uncompressed, jpg is compressed so typically 50% more data to move. Also with separate files the processing overhead is shared between the database server (retrieve link) and the web server (serving image) so my gut feeling is the process will be more efficient. I really dont see upside of storing in a database personally, probably why it is rarely done?
1 Like
Thanks, for all the input @turn3636 and @Hyperbytes, really appreciate it, stuff like this typically i get in my head, and then spend the next day testing, so saving me a day is great. Thanks guys.
I think it’s a case of just because you can doesn’t mean you should.
2 Likes
In my opinion there is absolutely no reason why you should want to save the images in a database.
You will be creating an extra, unnecessary load to your database when you need to fetch the images for display to the user. Web servers file system is much better way to server images directly and also leverage optimal caching both on the server and client side.
If you store your images in a database - you will have to create a special “fetch” pages that query the database and return just the image data to be used in an image tag. Or indeed as a base64 next to the existing record.
It is much better to store them as a file and just use server connect actions to manage the file together with the database record. So when the record is updated reupload and store the new file or when db record is deleted, delete also the file - much simpler.
And last but not least - base64 is not binary - but encoded binary as ascii characters usually used by cross systems transfers only - as ascii chars don’t get corrupted during the transfer. Like email attachments that should be able to be transferred by even servers from the '70s
So actually base64 encoding makes a file like 1,5 times bigger as every byte has to be encoded in 7bit ascii instead of 8bit binary. For you background info 
1 Like
Thanks for confirming all this George, much appreciated.
Unfortunately many of my sites land up quite large, like a 3.5 - 4mb homepage because in travel everything needs to be so visual with large high quality images so I am always looking for ways to make my pages smaller and load faster but retain the quality. This way is clearly not going to be a good solution for me, but was good to just get all the information.
When i took over this particular website the homepage was 16mb and too 18 seconds according to the google mobile test to load.
I have managed to get it down to 3.5 - 4mb now but the load is still 7 seconds according to the same google mobile test, while pingdom says the load time is less that 2 seconds.
I will find other ways to trim down filesizes more in some area as i go though.
Well having huge images, makes storing them in database even worse. So you shouldn’t do it at all indeed.
Just stick to files and also use jpegs with higher compression so it should be all fine
1 Like
I use Photoshop for every image I load on a website. Usually saving as .jpg with a quality of between 3 and 7. (Mostly 7). However, let me point you to Kraken Image Optimization.
They only cost $5 - $9/month for most heavy needs. You can plug your sites directly into them through their API or you can just upload your files and download them after they optimize them. I find that they optimize files outstandingly. I use to use Fireworks to do that, which was significantly better than Photoshop, but of course…Adobe killed that too.
I have an account if you want to login to it and try it. I get about 2GB/month of image processing. But do consider that in Photoshop at quality of 7, I might get an image down to 200kb. With Kraken, I can get it down sometimes to 90kb. Big savings in size!
Wappler should tie Wappler into something like Kraken, and let users pay an additional monthly fee to use it. That’d be awesome.
My image needs are quite a pain, lets say i have a site that needs header images at 1920px x 400px
I will have 5 saved .jpg files to serve that image best that all match the bootstrap 4 breakpoints.
I use a max image size of 135kb at very worst case scenario, but most images i can make way smaller than that. I use ImageOptim to optimise the images after I have all my cropping etc done which really helps massively.
I might have to push this site from the CDN to rather use an Amazon AWS image Bucket and use Cloudenary to server scaled images in the end to really optimise the image size to the very best it wan be. Could get a little pricey though.
I think that is overkill, personally. But either way, using a professional optimization algorithm is going to save you tons of file size regardless of how many dimensions you have for an image.
It’s still alive on my computer. Works as well as ever on Windows.
For basic batch processing (resizing, jpeg compression, sharpening etc.), this is excellent software I use a lot.
1 Like
It saved tons of size with the 5 image idea, a mobile user only has to download 20 images at around 20kb each which is sufficient for their viewport, while a desktop user will download 135kb images x 20
Desktop download size = 135kb x 20 = 2.7mb
Mobile download size = 20kb x 20 = 400kb
1 Like
Maybe you should try the integrated Image Resizer that we have in Wappler Paul
it is currently in use only with the Slideshow component - when you add like a whole folder with images.
It produces really good results and optimizes images pretty well.
Maybe we should make it available for more general usage and not only for the Slideshow.
We have plans to make a generic Assets Manager that will allow you to better organize your images per project and maybe also automatically resize them when needed.
2 Likes
Haha, I am going to be really honest here, i prefer using the server connect image resizer because i have so many more options, I can resize, then crop, then save my image to whever i like in the format i want at the quality i choose, and rename everything using a template. That being said I made my own in Wappler about a month ago, so on my website i have a serverconnect image resizer that i give 1 image or 100 images and it throws back at me 5 resized and renamed images exactly the way i want them, its fast and brilliant. It even gives the code block i need to add to the website so i can copy and paste it in afterwards.
The only thing i would love to have figured out how to code would have been a custom image cropping tool, like what Google has when you add an image to say google pages, it gives you that window that lets you define your own cropping.
But for now Wappler already saved me hours upon hours of cropping by making my own custom little tool, in about 30 minutes.
1 Like