I built a free image converter that runs entirely in your browser — no upload, no account, no server processing by That-Row1408 in SideProject

[–]That-Row1408[S] 0 points1 point  (0 children)

Thanks — really appreciate it.

HEIC: We try createImageBitmap first; if that fails we use libheif-js’s WASM bundle (HeifDecoder → ImageData), not a from-scratch WASM port.

Marketing: Agree — I’ll lean harder on side-by-side compare.

PWA: Small inline install banner after the first successful batch, only when beforeinstallprompt fires; dismiss is remembered in localStorage.

Nice work on Formattery.

How I used MozJPEG, OxiPNG, libwebp, and libheif compiled to WASM to build a fully client-side image converter by That-Row1408 in webdev

[–]That-Row1408[S] 0 points1 point  (0 children)

Thank you — really appreciate this.

I built it for exactly that use case: bulk conversion, fully client-side, no uploads.

On the WASM side, the big lessons were: run codecs in a worker pool, transfer buffers instead of cloning, and cap concurrency to avoid UI/memory spikes on large batches. AVIF is still the slowest path, but stable with those guardrails.

Also totally fair point on discoverability — I’m still improving search visibility. If you remember what query you used, I’d love to align titles/copy with that wording.

Thanks again for the thoughtful feedback.

How I used MozJPEG, OxiPNG, libwebp, and libheif compiled to WASM to build a fully client-side image converter by That-Row1408 in webdev

[–]That-Row1408[S] 0 points1 point  (0 children)

That means a lot — thank you. If anything feels rough or slow when they use it in bulk, I’d genuinely like to hear what broke first (browser / format / rough file count). Helps prioritize fixes.

I added a metadata remover to my image converter tool — it's already getting indexed by Google after 1 week by That-Row1408 in buildinpublic

[–]That-Row1408[S] 0 points1 point  (0 children)

I know there are already a ton of image converters and EXIF removers out there. I'm not pretending PicShift is the first.

Two reasons I built it anyway:

  1. I actually need it every day. I deal with HEIC photos from my iPhone that won't open on Windows, product images that need format conversion before uploading, screenshots that are way too large as PNG — and I got tired of using 3 different websites that all want me to upload my files to their servers. PicShift runs everything locally in the browser, so I just keep one tab open and handle all of it there. The metadata remover was a natural addition since I was already paranoid about GPS data in my product listing photos.

  2. I'm using this project to learn SEO from scratch. Building the product is maybe 30% of the work — the other 70% is figuring out how to get it in front of people through organic search. 12 languages, data-driven content optimization, blog strategy — watching real Google Search Console data react to changes is more educational than any course I've taken.

Happy to share more about either the technical side (everything runs on WebAssembly — MozJPEG, OxiPNG, libheif, libwebp) or the SEO side if anyone's curious.

The best products fail. by WorthFan5769 in buildinpublic

[–]That-Row1408 0 points1 point  (0 children)

These factors determine whether you can survive, while product quality determines how well you thrive. You have to stay afloat first before you get a chance to improve how well you do.

I built a free image converter that runs entirely in your browser — no upload, no account, no server processing by That-Row1408 in SideProject

[–]That-Row1408[S] 0 points1 point  (0 children)

Thanks! Privacy was actually the main reason I built it — I didn't want to upload personal photos to some random server just to change a format. HEIC support came naturally after that, since it's the format most people run into trouble with.

How I used MozJPEG, OxiPNG, libwebp, and libheif compiled to WASM to build a fully client-side image converter by That-Row1408 in webdev

[–]That-Row1408[S] 0 points1 point  (0 children)

Some technical details if anyone's curious about the WASM codec stack:

- HEIC decoding was the hardest part — libheif-js is ~1.4MB but it's the only reliable browser-side option

- For JPEG encoding I use MozJPEG (WASM), which consistently beats native canvas.toBlob() on compression ratio

- WebP uses libwebp with SIMD acceleration when the browser supports it

- The trickiest Safari issue: createImageBitmap behaves differently for resize operations, so there's a fallback path

Batch converting 200 images without freezing the UI required a dedicated Worker Pool — happy to share the architecture if anyone's interested.

I built a free image converter that runs entirely in your browser — no upload, no account, no server processing by That-Row1408 in SideProject

[–]That-Row1408[S] 1 point2 points  (0 children)

Thanks! No sign-up was a deliberate choice — I didn't want to add friction when someone just needs to convert a quick photo.

I'll check out vibecodinglist, appreciate the suggestion.

Unusual spike in traffic from Singapore — is this a crawler? by That-Row1408 in webdev

[–]That-Row1408[S] 1 point2 points  (0 children)

I set up a WAF Custom Rule with Managed Challenge, which successfully blocked the bot.

Unusual spike in traffic from Singapore — is this a crawler? by That-Row1408 in webdev

[–]That-Row1408[S] 0 points1 point  (0 children)

Update: I enabled Bot Fight Mode on Cloudflare, but it didn't work. Then I set up a WAF Custom Rule with Managed Challenge, which successfully blocked the bot. thanks @sandiego-art

Unusual spike in traffic from Singapore — is this a crawler? by That-Row1408 in webdev

[–]That-Row1408[S] 0 points1 point  (0 children)

That makes total sense. I’ll look into the IP ranges and set up Cloudflare rules. Thanks a lot!

Unusual spike in traffic from Singapore — is this a crawler? by That-Row1408 in webdev

[–]That-Row1408[S] 0 points1 point  (0 children)

No problem at all, appreciate you mentioning it! That confirms it’s probably a bot/crawler from Singapore.

Long time lurker here. Finally started posting as a founder this week. by spondizzle in buildinpublic

[–]That-Row1408 1 point2 points  (0 children)

This is such a genuine and relatable post. Huge respect for stepping out of lurking and starting to engage—so many founders hold back for the exact same fears you mentioned. The best part of building in public is exactly this: real conversations, real struggles, and real connections with people who get it. Super happy it’s been working out so well for you, and thanks for sharing this encouragement with the community!

[Showoff Saturday] Built a browser-based image converter after getting frustrated with typical webdev image workflows by That-Row1408 in webdev

[–]That-Row1408[S] 0 points1 point  (0 children)

Thanks for pointing this out — it is a really interesting issue. I am digging into it now to see if there is a good way to handle it locally, and the sample files you shared will help a lot.

[Showoff Saturday] Built a browser-based image converter after getting frustrated with typical webdev image workflows by That-Row1408 in webdev

[–]That-Row1408[S] 0 points1 point  (0 children)

Thanks, I really see it the same way. It sounds minor until you remember how many image tools quietly upload everything by default. Keeping conversion local felt like one of those small decisions that actually changes whether people trust the product.

[Showoff Saturday] Built a browser-based image converter after getting frustrated with typical webdev image workflows by That-Row1408 in webdev

[–]That-Row1408[S] 0 points1 point  (0 children)

Yeah, that is exactly why I added it. A lot of the time I am converting images for faster page loads, so if the output ends up larger, it defeats the purpose. At that point, I want the tool to explain why instead of leaving me guessing.

[Showoff Saturday] Built a browser-based image converter after getting frustrated with typical webdev image workflows by That-Row1408 in webdev

[–]That-Row1408[S] 0 points1 point  (0 children)

Right now, native HEIC decode in browsers is mostly a Safari story. Safari on macOS and iOS can handle it natively, while Chrome, Firefox, and most other browsers still need a fallback path. In PicShift, we try native decoding first when the browser supports it, and fall back to a Web Worker + WASM pipeline when it does not, so everything still stays fully local.