DEV Community: Dev Bhamaria

I built a way to send files from a PC to a phone with no internet

Dev Bhamaria — Wed, 04 Nov 2026 13:30:00 +0000

In my college lab, some PCs had no internet. I would finish a file on one PC, then find I could not get it to my phone. The only way out was to move to another PC and do the work again. That is why I added Share to phone to IHatePDF.

It sends files, or whole folders, from the PC to a phone. Nothing is uploaded anywhere and no app is needed on the phone.

How it works

You add files or folders, pick how the phone connects, and scan a QR code. There are three ways to connect:

	Same Wi-Fi	PC hotspot (offline)	Bluetooth (offline)
When to use it	PC and phone are on the same network (internet not needed)	No Wi-Fi network at all: the PC's Wi-Fi card makes a private hotspot	No Wi-Fi at all
On the phone	Scan one QR code, tap Download	Scan a QR code to join the hotspot, then one to download	Make Bluetooth visible, pick the phone in the app, tap Accept
Phones	Any (Android, iPhone)	Any (Android, iPhone)	Android only
Size limit	None	None	4 GB, and slow
Folders	Download as a .zip	Download as a .zip	Sent as one .zip
Needs	A network	A PC with Wi-Fi	Bluetooth on the PC and the phone

The hotspot is the one that matters for a lab with no internet. The PC makes its own Wi-Fi network, the phone joins it by scanning a QR code, and a second scan opens the download page.

Staying safe

The QR code stays active for 1, 5 or 10 minutes, and changing the time restarts the countdown. The link stops working when time runs out, when you press Stop sharing, or when you close the app. If the app turned the hotspot on, it turns it off again. For Bluetooth the app never picks a phone for you. You choose it from the phones it finds nearby.

What I have not tested

I have not tested it with an iPhone. The same Wi-Fi and hotspot modes are a plain web page, so an iPhone should work, but I have not checked. Bluetooth is Android only, because iPhones cannot receive files over Bluetooth. Share to phone is only in the Windows app. A browser tab cannot run it.

Code and install: https://github.com/Burthcer/IHatePDF (MIT)

I ran my PDF tools on a 5 GB file and a 10,000-page file. Here is what worked and what did not.

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

My last article tested IHatePDF on small PCs. This one goes the other way: very big files. I wanted to know where the tools stop working. I had huge files I wanted to compress, and the online tools I found had a size limit. I wanted to be sure my offline tool did not.

The two files

A 5.0 GB PDF of 1,436 scanned pages (300 dpi JPEG, every page different).
A 10,000-page text PDF, only 14.6 MB: a heading, 40 lines and a small table on every page.

Both ran in the Windows app, using the app's own memory budget. The 10,000-page run was on Windows 11 with 32 GB of RAM.

The 5 GB file

Tool	Result	Time	Most memory used by the app
Watermark	finished	86 s	924 MB
Page numbers	finished	56 s	1.0 GB
Merge (+ 20 pages)	finished	65 s	1.0 GB
Protect (AES-256)	finished	62 s	990 MB
PDF/A	finished	71 s	983 MB
Compress	finished, every image recompressed	743 s	2.1 GB

Five of these tools used about 1 GB of memory or less on a 5 GB file. Compress is the heavy one: about 12 minutes and 2.1 GB.

What did not work: previews over 2 GB

Tools that show page thumbnails could not open the 5 GB file at all. Rotate sat on "Loading pages…" with no thumbnail for 10 minutes.

The cause is a limit in the page engine: it cannot allocate a block of memory of 2 GB or more (new Uint8Array(2 GB) fails, in the page and in workers), and the PDF viewer library keeps one the size of the file. So page previews cannot open files over 2 GB. The app now says so: "This PDF is 5.0 GB. Page previews work up to 2 GB." It also lists the tools that still work, and Split, which needs previews, shows the same message.

The 10,000-page file

All 14 tools finished.

Tool	Time	Most memory used by the app
Watermark	6 s	1.2 GB
Rotate	4 s	1.2 GB
Page numbers	5 s	1.2 GB
Merge (+ 20 pages)	3 s	0.9 GB
Organize (reverse order)	4 s	1.2 GB
Split (every page to ZIP)	5 s	1.3 GB
Protect (AES-256)	4 s	0.9 GB
Compress	17 s	1.7 GB
PDF/A	4 s	0.9 GB
PDF to Markdown	32 s	2.1 GB
PDF to Word	9 s	4.1 GB
PDF to Excel	67 s	2.0 GB
Redact (a word on every page)	63 min	1.7 GB
Edit PDF (open and retype a paragraph)	3 s	1.5 GB

Twelve of the fourteen finished in 32 seconds or less. Two things to know:

PDF to Word on 10,000 pages needs about 4 GB of RAM. On a 4 GB lab PC the memory limit would slow it down or stop it, so split such a file first.
Redact on every one of 10,000 pages takes about an hour. It redraws each page. That is fine for a few pages and slow for all of them.

What I would change

What surprised me most was how unoptimised IHatePDF was at the start. In the early version, a file of about 100 MB used roughly 5 to 7 times its own size in RAM. I had to optimise it. (The 5 to 7 times figure is from my own early testing, not from the test report.)

Code and the full test report: https://github.com/Burthcer/IHatePDF

I didn't want to pay a monthly subscription for dictation, so I built one that runs on my GPU

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

I wanted to dictate on my PC without paying for a subscription. So I built Wisperno: hold a hotkey, speak, release, and the text is pasted into whatever app has focus.

It runs fully offline. Whisper large-v3-turbo transcribes on the GPU, and a small quantized language model cleans up the text. There are no network calls once the models are on disk, so no audio or text leaves the PC.

What it does

There are two ways to dictate. Direct Dictation uses no language model at all. A rule-based formatter capitalises pronouns, strips filler words and detects lists in well under 10 ms. Polish sends the text through the local model to fix grammar and filler. You pick per hotkey: tap Ctrl+Alt for direct dictation, Alt+C for polish.

A long pause (1.3 seconds or more) starts a new paragraph. I first tried segment-level timestamps from Whisper to detect the pause, and they could not see it at all. Word-level timestamps can.

How fast is it

I measured it on my laptop (RTX 4070 Laptop GPU, 8 GB) with tests/benchmark_models.py. Whisper stays loaded the whole time, so the VRAM numbers match the real app.

Preset	VRAM	Decode speed	100 words
Turbo Flagship (default)	3491 MB	113.8 tok/s	0.82 s
Eco	3621 MB	103.3 tok/s	0.89 s
Standard	3691 MB	91.7 tok/s	1.04 s
Flagship	5119 MB	63.1 tok/s	1.48 s

The smaller presets are faster and use less memory. The bigger ones keep a little more fidelity: 97.6% for the two smallest, 98.8% for the two 3B models, measured on raw model output.

Upgrading llama-cpp-python from 0.2.90 to 0.3.26 made every preset about 20 to 30% faster with the same output. For the default preset that was 89.3 to 113.8 tokens per second. VRAM did not change.

Making a small model behave

A cleanup model can answer your dictation instead of cleaning it. If you say a question, it may reply to it. So the app runs every result through a guardrail (sanity_check()), and I wrote a suite of adversarial prompts meant to make the model answer back. With the guardrail on, that suite passes 100% on every preset.

A bug my own tests found

Live Transcription is a separate mode for meetings and lectures. My first design re-decoded only a sliding window of the latest audio. The test suite showed it silently dropped real words. The current version re-decodes the whole unconfirmed audio buffer every 0.6 seconds. It runs about 13.5 times faster than real time (RTF 0.074), with no second model loaded.

What it cannot do

Windows only, and it needs an NVIDIA GPU. Below about 2 GB of VRAM it falls back to a slow CPU mode.
It is a source install. The packaged build is about 4.7 GB, too big for GitHub.
The fidelity scores above are on raw model output.

Code, benchmarks and install steps: https://github.com/Burthcer/Wisperno (MIT; the models keep their own licences).

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.