Mirowl
Search all your screenshots via a local OCR-powered AI
112 followers
Search all your screenshots via a local OCR-powered AI
112 followers
A frictionless, local-first Mac app to index and search all your screenshots and image assets. Built with Rust/Tauri for zero footprint and powered by native macOS Vision for 10x OCR accuracy. Optional cloud, no tracking—just pure utility.
Free Options
Launch Team / Built With
Render Sandboxes: a computer for every agentIsolated compute, persistent state and a real filesystem
Promoted
Built a K1 document OCR pipeline professionally and spent the last week generating hundreds of AI video storyboard screenshots across GPT and Kling. The screenshot search problem is real — I was manually scrolling through folders looking for specific reference images. Curious how Mirowl handles images with minimal text — like a cinematic still or a product photo with just a logo. Does the AI understand visual content beyond just OCR, or is it purely text extraction from images?
Native macOS Vision for the OCR instead of a bundled cross platform model is the choice that earns trust here. On device accuracy and a near zero idle footprint are exactly what a menu bar utility lives or dies on, and Rust plus Tauri is the right call for an indexer that has to stay invisible. Read your reply to Joe on the Pro tier visual descriptors. The follow up I would push on: when both layers are available, does a query rank OCR and visual embeddings together, or does OCR run first and visual only kicks in as a fallback? The two paths can disagree, and a screenshot with no text but strong visual content should still be able to outrank a partial OCR match. And on a library of tens of thousands of old screenshots, does the first full index throttle itself, or is the cold start the painful part?
@zimasilevuyo you have a very sharp eye for the architecture. right now we handle the ranking by merging the native ocr results with the text descriptors generated in the pro tier. we are currently using a vision api for those rich descriptors when users opt-in which provides a huge jump in search capability without needing local vector database overhead yet. i haven't moved to full local visual embeddings yet because i wanted to keep the ram usage as low as possible for the v1 release but it is definitely something i am exploring as local models get more efficient. for the cold start the rust indexer is designed to be polite to the cpu and we handle the initial load in a throttled background thread so it won't freeze your machine even with ten thousand shots. it is more of a slow burn than a heavy burst.
Local OCR is a smart call, especially for screenshots that often have personal stuff in them. Curious which engine you went with under the hood, Apple Vision or something custom? I work with on-device OCR too and the accuracy on dense text was the hardest part to get right.
@erdembilgin Great question! The accuracy on dense text is definitely the 'final boss' of local OCR.
For Mirowl, I moved entirely to the native Apple Vision framework for the text extraction. In my testing for v1.1.0, it was spot on compared to general models, especially for high-res Retina shots.
For the auto-categorization and tagging, I’m using a local model so that we can keep the entire pipeline on-device.
@safiullah_mohamed Makes sense. Keeping the whole pipeline on-device is the right call for screenshots. Nice work, will keep an eye on Mirowl.
@erdembilgin Thanks, Erdem! You are spot on, privacy is exactly why I started with screenshots.
But I actually designed the engine to be flexible, you can point Mirowl at any folder on your Mac (like project assets, downloads or design archives) and it will index and tag them exactly the same way. The goal is to make all your visual knowledge searchable, no matter where it's stored. Appreciate you following along!
Nice that everything happens on device, as i state with thoth, our devices have more computing power than the Apollo guidance computer so why offload computing to the cloud !
Quick question: does Mirowl rename the files or propose titles based on the content, or is it search-only? Auto-naming "Screen Shot 2026..." into something findable would be huge for me. To keep that local it could be done with apple intelligence
@matthieu_v Love the Apollo Guidance Computer analogy! You’re absolutely right - our local hardware is more than capable of handling these workflows without a 'cloud tax.'
Regarding re-naming, Currently, Mirowl keeps the original file name on your disk to ensure we don't disrupt your existing filing system, but allows you to rename the asset within the app for searchability.
However, auto-naming 'Screen Shot' files is one of my top roadmap items. I’m actually exploring how to leverage Apple Intelligence and local LLMs to do exactly that in the next version. It’s the final step to truly killing the desktop clutter!
rust/tauri + native Vision — nice combo. built similar local-first on mac, the OCR pass got memory-heavy past a few thousand shots. you indexing incrementally on new ones or batching the lot?
@qifengzheng Great point! Memory management is definitely the biggest challenge when you're doing local OCR at scale. For mirowl, I handled this by using the native macOS Vision framework directly through Rust. Since it’s optimised by Apple to use the Neural Engine, the footprint stays surprisingly lean. To keep things stable, I use a native folder watcher to index new shots incrementally, but for larger batches, I built a sequential worker pipe. That way, the app only ever processes one image at a time, which keeps the memory usage flat whether you're indexing 10 images or 1,000. It’s been feeling really snappy so far!
@safiullah_mohamed the one-at-a-time worker pipe is the right call for flat memory — i'd have reached for batching and regretted it. does the watcher ever fall behind on a big import, or does the queue just absorb it?
@qifengzheng Exactly. I kept the discovery and heavy lifting separate to avoid that. The watcher just handles the high-speed 'ingress' - it indexes the file locations in the DB almost instantly and then pushes the IDs into a Rust queue.
@sharbani_sengupta slides and workshop notes are such a huge use case for this. it is basically a visual memory for all those things you swear you will remember later. i have heard the call for windows a few times today so i am officially starting a waitlist for it on the site.