Image manipulation is one of the most universal tasks on the internet. Everyone does it — designers, marketers, developers, content creators, anyone with a phone. I work with images constantly: in website design, in narrative formation for public affairs campaigns, and in social media audience activation. Every time I needed a simple operation — convert a PNG to JPG, crop to an Instagram story size, strip EXIF data before sharing — the available tools wanted me to create an account or upload my files to someone else’s server. In 2026, with AI companies, governments, and bad actors all hungry for image data, that felt increasingly reckless.
After shipping 145 PDF tools with PDF Pony and 101 GIS tools, image processing was the next obvious domain to cover. I built ImageNurse during a deliberate sprint over the weeks after Christmas 2025, when Anthropic doubled Claude Code credits. It was part of a conscious push to ship multiple browser-based tool platforms in rapid succession — proving that a solo developer with the right AI workflow can cover entire functional domains that would have taken teams months.
ImageNurse is a 120-tool image processing platform that runs entirely in the browser. No uploads, no accounts, no subscriptions. It converts between eleven formats, batch processes entire folders, generates social media assets for every major platform, removes backgrounds with AI, and compresses to exact file size targets. It works offline. I internationalized it into thirteen languages, including right-to-left support for Arabic, Hebrew, and Farsi.
This is the engineering story behind it.
Replacing Adobe Creative Cloud with tools I actually control#
I have been a heavy Photoshop user for years. Adobe Creative Cloud is powerful software. But Adobe as a company has become increasingly hostile to the people who pay for its products. The early termination fees are punitive — cancel your annual subscription mid-year and Adobe charges you half the remaining balance. The dark patterns in their cancellation flow are deliberately designed to retain users through friction rather than value. Their 2024 terms of service update granted Adobe broad rights over user content, including for AI training purposes, which drew enough backlash and FTC scrutiny that they partially walked it back. But the pattern is clear: Adobe treats its users as a resource to be extracted from, not a customer to be served.
I decided to stop complaining about it and start replacing it. Not every Photoshop feature needs a desktop application. The operations I reach for most — format conversion, compression, cropping, resizing, background removal, batch processing, metadata management — are all operations the browser can handle natively. ImageNurse is my answer to the question: how much of a professional image workflow can I move out of Creative Cloud and into a tool I control completely? The answer turned out to be most of it.
How Claude Code made 120 tools feasible for a solo developer#
Building 120 image tools as a solo developer would have been impractical without AI-assisted development. I built ImageNurse using Claude Code, the same workflow I used for PDF Pony and GIS Tools. The process was: describe a tool’s behavior, review the generated code, test it against real inputs, refine.
Claude Code was essential in three ways. First, speed — it compressed what would have been months of implementation into days. The sheer velocity of AI-assisted development still catches me off guard. I could describe a complete tool and have working code back in seconds, iterate on it in minutes, and move on to the next one. Across 120 tools, that compression is the difference between a days-long project and a months-long one. Second, format expertise — image formats have deep, idiosyncratic internals, and Claude Code helped me navigate the edge cases across HEIC, AVIF, TIFF, PSD, and other formats far faster than reading specs alone. Third, boilerplate elimination — with 120 tools sharing common UI patterns, Claude Code handled the repetitive scaffolding so I could focus on the architectural decisions that actually mattered: the processing pipeline, memory management, and privacy guarantees.
The hard work was not writing code. It was understanding each use case well enough to make good design decisions — the same lesson I learned building PDF Pony. AI handles the typing. The thinking is still the job.
Designing the processing pipeline with Canvas API and WebAssembly#
The core architectural decision was choosing how to process images at high performance without a server. I built the pipeline around two browser capabilities: the Canvas API for pixel-level manipulation, and WebAssembly for computationally intensive operations.
I use the Canvas API for the spatial operations — resizing, cropping, rotating, flipping, adding watermarks, extracting colors. For the heavy computation — AVIF encoding, WebP compression, HEIC decoding — I use WebAssembly modules that run at near-native speed. The combination means that operations which feel instantaneous to the user are genuinely running at high performance locally, not offloaded to a server.
I round out the pipeline with the File System Access API for reading input files and writing output directly, all within the browser sandbox. No data touches a server at any point. This is the same privacy-first architecture I use across PDF Pony and GIS Tools — but the image processing domain demanded a different set of engineering tradeoffs.
Engineering eighteen format converters that handle edge cases#
I built eighteen format converters: PNG to JPG, JPG to WebP, HEIC to JPG, SVG to PNG, AVIF to PNG, TIFF to JPG, BMP to PNG, GIF to WebP, PSD to PNG, ICO to PNG, and more — each with format-specific options like quality sliders, transparency handling, and color profile management.
The engineering challenge was not any single conversion but achieving consistency across all of them. Each format has its own edge cases that I had to identify and handle — HEIC files from iPhones carry EXIF orientation data that needs to be applied during conversion, SVG rasterization requires choosing a target resolution, TIFF files can be multi-page, PSD files can have layers. Building one converter is straightforward. Building eighteen that all handle their format’s quirks correctly required understanding each format’s internals, not just its API surface.
Building batch processing with client-side memory management#
Individual tools are useful. But I designed ImageNurse around batch operations because that is where the real productivity gains are. I built batch tools across every major category — batch format conversion, batch resize, batch compression to quality targets, batch compression to file size targets, batch crop to aspect ratio, batch rotate, batch strip metadata, and batch web optimization.
I also built compound operations: batch rename and convert combines file renaming with format conversion in a single pass — useful for standardizing asset libraries. The ZIP exporter bundles batch output into a single download. These are the tools that turn a ten-minute manual task into a ten-second automated one.
The significant engineering challenge with batch processing is memory management. The browser does not have unlimited memory, and processing large images in sequence can exhaust it. I designed the pipeline to process images sequentially, releasing memory between operations, with progress feedback so the user knows what is happening. Getting this right was essential — a batch tool that crashes on the fortieth image is worse than no batch tool at all.
Covering every social media platform’s image requirements#
Social media platforms each have their own image dimension requirements, and those requirements change regularly. I built presets for every major platform: Twitter/X posts and headers, Instagram posts and stories, LinkedIn posts and banners, Facebook share images, Pinterest pins, YouTube thumbnails, and TikTok covers.
I also built an OG image generator that I find particularly useful as a developer — it crops and scales images to the Open Graph standard with an OG safe-area preview that shows where different platforms will crop. The OG + Twitter Card pack outputs all required social sharing sizes in a single operation, which eliminates the tedious manual resizing that content creators deal with every time they publish.
Running AI background removal and face detection client-side#
I integrated AI models that run entirely in the browser. The background remover isolates subjects from their backgrounds without any server processing. The face-aware crop detects faces and centers crops around them — useful for generating profile images and headshots from group photos.
I chose to run these models client-side deliberately. It would have been simpler to call a server-side API for background removal. But that would mean uploading user images to a remote server — exactly the privacy compromise I designed ImageNurse to avoid. The tradeoff is that browser-based models are smaller and less capable than server-side alternatives. For the use cases I target with these tools, the quality is more than sufficient, and the privacy guarantee is worth the tradeoff.
Internationalizing 120 tools into thirteen languages with RTL support#
Image manipulation is universal, and I wanted ImageNurse to reflect that. I deliberately internationalized it into thirteen languages — English, French, Spanish, German, Japanese, Korean, Portuguese, Chinese, Italian, Dutch, Arabic, Hebrew, and Farsi. The choice of languages was strategic: Korean, Japanese, Arabic, and Hebrew in particular represent large online populations that are underserved by English-only image tools, and reaching them is essential for broadening the site’s global SEO footprint.
The last three languages required me to build full right-to-left layout support, which means the entire UI reverses direction — navigation, tool cards, form layouts, and text alignment all flip. This is not a CSS trick; it required me to make the application aware of text direction at every level of the component hierarchy.
I also built fully localized URLs — not just translated UI text but proper localized paths for every tool in every language. This means users in any supported language get a native-feeling experience and search engines can index language-specific pages. Doing this across 120 tools in thirteen languages is a combinatorial challenge, but the result is a genuinely global product that can rank in local search results worldwide.
ImageNurse is free, works offline, and processes everything locally.
