Stirling-Tools
[Bug]: Compress PDF doesnt work
Installation Method
None
The Problem
The PDF-Compress function doesnt work. If I select a pdf it only gets a few kb smaller, doesnt matter how big it is
Version of Stirling-PDF
latest
Last Working Version of Stirling-PDF
0.43.2
Page Where the Problem Occurred
No response
Docker Configuration
Relevant Log Output
Additional Information
No response
Browsers Affected
No response
No Duplicate of the Issue
- [x] I have verified that there are no existing issues raised related to my problem.
Seconded, kinda. I started with a 51MB, 117 page file... I extracted 2 pages, still 51MB. THEN i tried to compress, still 51MB.
Then I got my work laptop, opened Adobe, extracted the same 2 pages, immediately down to 1MB
I dont have special parameters. I use the standard tool (pdf-compress). It doesnt matter if I use my docker version or your official web applikation.
What parameters are you compressing with Can you provide logs or files?
for my "similar" issue, here's what I had:
I just clicked on "Extract Page(s)" from the main screen. I got this in my docker log: 2025-03-10 04:38:40.209278+00:0000:38:40.208 [qtp1370822209-65] INFO s.s.S.c.a.RearrangePagesPDFController - newPageOrder = [49, 50] 2025-03-10 04:38:40.209473+00:0000:38:40.209 [qtp1370822209-65] INFO s.s.S.c.a.RearrangePagesPDFController - totalPages = 117
Output file was 2 pages, but still the same size as the 117 page original.
Then to Compress, I just clicked on "Compress" on the top banner, left the settings default as shown:
Docker Log shows:
2025-03-10 04:39:39.628344+00:0000:39:39.627 [qtp1370822209-79] INFO s.s.SPDF.utils.ProcessExecutor - Running command: qpdf --optimize-images --recompress-flate --compression-level=5 --compress-streams=y --object-streams=generate --no-warn /tmp/input_16628756068428835146.pdf /tmp/output_13909192155282413624.pdf
2025-03-10 04:39:51.685346+00:0000:39:51.684 [qtp1370822209-79] WARN s.s.SPDF.utils.ProcessExecutor - qpdf succeeded with warnings:
2025-03-10 04:39:51.753856+00:0000:39:51.753 [qtp1370822209-79] WARN s.s.S.c.api.misc.CompressController - Optimized file is larger than the original. Returning the original file instead.
Can you change compression level from 5 to 9? Is that suitable?
2025-03-10 22:33:56.968125+00:0018:33:56.967 [qtp355677068-50] INFO s.s.SPDF.utils.ProcessExecutor - Running command: qpdf --optimize-images --recompress-flate --compression-level=9 --compress-streams=y --object-streams=generate --no-warn /tmp/input_863533155438163280.pdf /tmp/output_17530627149630344779.pdf 2025-03-10 22:35:02.326863+00:0018:35:02.326 [qtp355677068-50] WARN s.s.SPDF.utils.ProcessExecutor - qpdf succeeded with warnings: 2025-03-10 22:35:02.378574+00:0018:35:02.378 [qtp355677068-50] WARN s.s.S.c.api.misc.CompressController - Optimized file is larger than the original. Returning the original file instead.
Hello,
I'm experiencing a similar issue with the PDF compression feature in Stirling-PDF. Using a default Docker installation of the latest version (0.44.1), I attempted to compress a 32MB color PDF containing images. Regardless of the compression level selected, the file size reduction was less than 1MB. In contrast, when using Foxit PDF, I achieved reductions between 6MB and 22MB. This behavior is consistent across other PDF files I've tested.
Additionally, I tested the same files using the online demo version of Stirling-PDF and observed similar results, indicating that the issue is not isolated to my local setup.
I've attached screenshots illustrating the file sizes after compression at both levels :
Just for the record, I'm facing the same problem on the latest v0.44.3, having a compression less than 5% on some files mostly with images, even at maximum level. When falling back to Stirling PDF v0.33.1, the same file compressed at level 3 (of 4) went correctly from 506k to 81k
Edit : I could generate a sample using this issue generated to a pdf as a reference Comparing v0.33.3 with the old behavior : 4 levels, with level 4 as heavily destructive and v0.44.1 with the 9 levels
Given the quality of the images, it seems to me that the max level (9) of the new system is much less aggressive than the max level (4) of the older system. It seems in fact close, but still less destructive than the level 3 of the older system (which gave good result in weight/quality for readability, I'm mostly using this one) This would explain why the new 9 levels does not compress as much as expected on some files.
Coming from the older levels, I would expect having old level 3 = new level 7, and old 4 = new 9 in compression levels.
github.com-_Optimized_0.33.1_lv4.pdf : 159 kb github.com-_Optimized_0.33.1_lv3.pdf : 230 kb github.com-_Optimized_0.44.3_lv9.pdf : 199 kb github.com-_Optimized_0.44.3_lv7.pdf : 256 kb github.com-.pdf : 492 kb
If anyone still facing compression issues can email me the pdf at [email protected] I can take a look at the unique usecases for the compression
@Frooodle Seems out post crossed together, I've updated my previous message with a sample using this issue as a reference.
I think those levels are quite acceptable and personally I have found the old lv4 to be to destructive So personally I am happy with where our current compression logic sits
Well, not sure if it is a debate or not, but I think it would be better for each user to decide by himself what to chose. Everything is already in place : a dedicated page for compression, the complete warning in the text, and the selector with multiple levels. I suppose a part of the problem of the compression level not working on some case it because it is not destructive enough in said case. Or not as expected for the selected level. Having the max lv9 even less than the older lv3 is surprising.
As an example, from time to time I do have a PDF I want to archive, but the embedded images are just for decoration and were integrated without any work on them, at an absurd file size. I can remove or at least reduce them, but it will require to edit each file manually. It is much faster to compress those pdf with a high image compression level (so destructive enough), and it will not alter the whole layout. In the same manner, to keep the information in the images at a readable level, there are other compression levels available.
edit : something I though about meanwhile, that could help in some situation when giving the full access is not desired : having an option to reduce the levels available in the UI selector. Same manner as the ui/languages: [ ] setting, or simply a "max level allowed for compression" setting. If not set, the whole compression level range is available in the UI, with the max level being as effective as supposed.
Same problem here. Our users don't use our stirling 0.45 istance to compress files because ilovepdf can compress more and we are afraid that they are going to use external pdf tools simply because they are used to them.
I add that "Auto Mode" is not producing files of the desired size. IMHO because max compression is limited by this new levels.
Is there any way you can provide this file for us to test with?
Sorry I vanished off of here, been travelling for work the last month, busy days. Unfortunately, I cannot share these, as they are sensitive work documents. But it seems by the comments here it is pretty obvious there's an issue of the compressed file not meeting people's expectations.
Per my original comment here: I extracted 2 pages from a 117-page 51MB pdf, and the output file was the same 51MB size, despite losing 98.2% of the pages. (extraction is a different issue than compression, but definitely an issue) Compressing the original 117 page PDF in SterlingPDF did not reduce size at all. Compressing the original 117 page PDF in Adobe reduced the size to 2MB with no noticeable loss in quality
While I'm not necessarily expecting the same compression quality as Adobe, it is a level of compression that has been ingrained for many of us looking for an alternative.
I want to use the latest version of UI compression feature to roll back to version 0.33.1，how can I do it？
Are you able to send the PDF that you are unhappy about being compressed with our current impl I'd rather fine tune and add compression features to our existing to keep you and other users happy
Are you able to send the PDF that you are unhappy about being compressed with our current impl I'd rather fine tune and add compression features to our existing to keep you and other users happy
This is not convenient to provide. The PDF probably contains some tables, and the new version of the compression does not seem to handle it.