Samsung Internet's dark mode turned my orange buttons dark red. My fix is only partial.

Dev Bhamaria — Wed, 14 Oct 2026 13:30:00 +0000

My portfolio uses one accent colour: orange, #ff5714, which is RGB 255, 87, 20. On a friend's phone the orange buttons showed up dark red.

I first noticed it when a friend sent me a screenshot. Then I tested it on my own phone and saw the same thing.

The cause was Samsung Internet's dark mode for web pages (that is the name I know it by). I only saw it in Samsung Internet on phones. I did not see it on PC browsers. My page already says it is dark (color-scheme: dark in the CSS and a color-scheme meta tag), and the browser still changed the colours.

What I tested

I made a test page that paints the same orange eight ways and opened it on my phone (Samsung Internet 30.0, which reports Chromium 143). I measured the colours from screenshots.

How the orange was painted	Intended	Seen on my phone
Plain CSS fill	255, 87, 20	143, 0, 2 (dark red)
CSS gradient	255, 87, 20	72, 0, 2
Inline SVG	255, 87, 20	183, 12, 3
Box shadow or border	255, 87, 20	204, 34, 1
Image stretched to fit	255, 87, 20	91, 10, 4 up to 129, 43, 13
Small image tile at natural size	255, 87, 20	255, 110, 42
Canvas	255, 87, 20	255, 86, 21
Orange text	255, 87, 20	255, 119, 53

Only the canvas came out right. A small, unscaled image tile came out close.

Things I tried that did nothing: color-scheme: light on the element, forced-color-adjust: none, isolation: isolate with will-change: transform, print-color-adjust: exact, a color-scheme meta tag with both values, and prefers-color-scheme media queries. The phone also told the page that dark mode was not on, and still changed the colours.

I don't know Samsung's actual algorithm and couldn't find documentation for it. The table is a pattern from my tests, not a proof.

I also tried Chromium's own forced dark mode on desktop (Edge with WebContentsForceDark). It did not reproduce the problem: plain fills stayed correct. So Samsung's behaviour is different, and desktop Chrome is not a good stand-in for it.

The fix

Since a small unscaled image survived, I paint the orange as a 10 by 10 pixel SVG that repeats at its own size, instead of as a CSS colour:

--acc-tile: url("data:image/svg+xml,%3Csvg xmlns='http://www.w3.org/2000/svg' width='10' height='10'%3E%3Crect width='10' height='10' fill='%23ff5714'/%3E%3C/svg%3E");
--acc-fill: var(--acc-tile) repeat border-box;

Then 25 rules that said background: var(--acc) now say background: var(--acc-fill), with border-color: transparent so no dark red outline appears. A few other things had to change too:

The email underline was a gradient. It is now a separate strip, and the hover effect uses clip-path instead of resizing, because resizing would scale the image.
The play triangle in the Auto-scroll button was a CSS border triangle. It is now a filled box cropped with clip-path.
The university logo is a white PNG on a white CSS plate, and the phone turned both grey. A small script now draws the plate and logo on a canvas, with an aria-label for screen readers.

On desktop browsers the orange still measures exactly 255, 87, 20, so normal visitors see no difference. On my phone, after the fix:

What the fix does not solve

This is much better, not solved.

The orange is lighter. The buttons now measure 255, 110, 42, a bit peachy. I tried darker tiles (seven different oranges) and all of them came out at almost the same colour, so I can't compensate that way.
Orange text is still lighter (255, 119, 53). I didn't fix it.
The page background is still darkened, from 12, 12, 11 to about 2, 2, 0.
Some plain orange is still used for borders, outlines and hover states. I haven't checked each of them on the phone.
The light resume sheet can't stay light. A white sheet became dark grey, and nothing I tried stopped it. So the resume page now shows a short note to Samsung Internet users, based on the browser's user agent string. If Samsung changes that string, the note disappears. I tested the note on my own phone in Samsung Internet and it shows there.
Chrome's own forced dark mode would make the fix darker. In the desktop simulation, my tile became 217, 51, 0.
The code is harder to read. The orange is now an image behind two CSS variables, and the logo needs JavaScript.

What I haven't tested

Chrome on Android with its auto dark mode flag, Firefox, Safari, and Samsung Internet on desktop. I also haven't checked whether the dark mode alters the project screenshots.

If it happens to you

Try your site in different browsers before you ship it. I only found this because a friend happened to use Samsung Internet.

The fix is in the commit history of my portfolio repo: https://github.com/Burthcer/portfolio

If you know how Samsung Internet decides what to darken, I'd like to hear it.

What happened when I ran my PDF tools on a PC with 1 GB of memory

Dev Bhamaria — Sun, 11 Oct 2026 13:18:50 +0000

IHatePDF is a free, open-source set of 28 PDF tools that runs on your own machine. Nothing is uploaded. That also means it has to live with whatever memory your PC has, and scanned PDFs get big fast. So I tested what happens on small machines.

The test

I generated dummy scans: 300 dpi JPEGs of 10, 50, 150 and 500 MB (the 500 MB one is 144 pages). I ran Compress, Watermark, Merge, Rotate, Page numbers and PDF to Word on all of them. To pretend to be a smaller PC, I forced a memory budget for the app: 624 MB (a 4 GB PC with some margin), 1 GB (4 GB), 3 GB (6 GB), 4 GB (8 GB), 8 GB (16 GB), and no limit. The test machine is a Windows 11 laptop with 32 GB of RAM, running the installed app, not a dev build.

I wanted to test low memory because I want this to run on laptops and college PCs, not just on my own machine.

Version 1.3.0 failed

At a 1 GB budget, Compress stopped on every scan, even the 10 MB one, within a second or two. Watermark on the 500 MB scan stopped too.

Version 1.3.1

Same machine, same 1 GB budget:

Scan	Compress result	Time
10 MB	831 KB	2.9 s
50 MB	4.04 MB	10.6 s
150 MB	11.7 MB	31.3 s
500 MB	38.4 MB	120.6 s

Watermark on the 500 MB scan took 2.6 s, with the whole app peaking at 1.1 GB.

Across all six tools and all six budgets, nothing failed outright on the 6 GB, 8 GB and 16 GB budgets. At the tightest budgets some jobs slowed down but finished, and none of the 144 scan runs or 56 student-file runs was stopped.

Where it still breaks

I wrote the limits into the report as well:

Compress can stop with "Windows is almost out of memory" when Windows itself is within about 160 MB of the memory it keeps free. Other tools slow down and finish.
PDF to Word leaves out sideways (rotated) text, in any language.
Page previews are about 8 times slower at a 1 GB budget.

The app now refuses a single 300-megapixel image before starting (0.4 s), and stops a running job in about 2.4 s if Windows is down to 300 MB free. It stays usable afterwards.

What surprised me was how much memory the app used. If I did it again, I would design for low memory from the first day, instead of changing the structure of the code later.

DEV Community: Dev Bhamaria