MakeACopy: an offline Android document scanner with OCR and no cloud

Why this app exists now that Microsoft Lens is gone

The positioning of MakeACopy starts from an event rather than from a feature. With the discontinuation of Microsoft Lens, many users are looking for a reliable way to scan documents on Android, and the project describes itself as an open-source offline document scanner with OCR for Android, designed for privacy-friendly and self-hosted document workflows.

The app digitizes paper documents into searchable PDFs while keeping the entire processing pipeline on the device. It works completely offline and avoids any cloud services, telemetry or tracking.

The design difference it claims against Lens is not a better camera filter. The project lists fully offline operation, no tracking or telemetry, open source and auditable code, and a design intended for long-term self-hosted workflows. Instead of integrating into a cloud ecosystem, it focuses on local processing and interoperability with tools like SambaLite, paperless-ngx and Syncthing.

That interoperability is the part that makes it interesting beyond being a scanner. The intended combination is with SambaLite, a sibling project by the same author, to create a fully automated mobile document workflow.

Paper document
      ↓
Scan with MakeACopy
      ↓
Inbox folder
      ↓
SambaLite folder sync
      ↓
NAS / archive (e.g. paperless-ngx)

Read as a pipeline, each arrow is a handoff between two separate programs. The phone scans into a watched inbox folder, the sync tool moves it to a NAS, and the archive system processes it. The setup effectively turns a smartphone into a privacy-friendly mobile network scanner for self-hosted document archives.

The project's own framing is deliberately flat about all this. It treats privacy and offline operation as technical design decisions, not as moral or political statements, and says users should evaluate it on its concrete features and implementation rather than on positioning or narratives. That is a reasonable thing to read before choosing a scanning app, since the offline choice has costs that come later.

Two editions and two OCR flavors, and why the size difference exists

The build matrix is the most concrete thing in the readme, and it explains the app size that users notice.

Two editions are controlled via the Gradle property edition. The Full edition covers 23 OCR languages including CJK, Arabic, Hindi, Thai and Turkish, ships 5 fonts including CJK and Devanagari, and produces an arm64-v8a APK of about 99 MB. The Light edition is English plus German with 1 font, NotoSans, and an APK of about 58 MB.

The size is a direct consequence of the offline requirement. To ensure fully offline operation, the app bundles OCR language models, fonts and image processing components locally, which significantly increases the app size but avoids any cloud dependencies or on-demand downloads. The readme makes the argument as a slogan, that 100 MB are not a sign of excess but of consistency.

Both editions share the same ML-based document detection with an ONNX model, the same OpenCV image processing, and full offline functionality. Both use an operator-stripped ONNX Runtime build containing only the operators required for document detection, and inference runs on the ONNX Runtime CPU execution provider in both. XNNPACK and NNAPI are not built in, because they brought no benefit for the bundled models. The Light edition additionally ships fewer OCR language models and fonts and uses a minimal ONNX Runtime AAR to reduce APK size further.

The second dimension is the ocr flavor, which selects the OCR backend. The paddle flavor uses PaddleOCR V5 and is the published flavor for F-Droid and Google Play, using PaddleOCR only, without Tesseract runtime, Tesseract language data or OCR dictionaries. The standard flavor is Tesseract only, the legacy flavor for existing Tesseract language data and workflows, available via GitHub Releases, with no PaddleOCR assets bundled.

The Full plus paddle combination is what is published on F-Droid and Google Play. The standard Tesseract flavor and the Light edition are available via GitHub Releases only, which is the practical constraint for anyone who needs Tesseract or needs to keep the install small.

What the scanner actually does to the page

The feature list describes a pipeline from capture to output, and the interesting steps are the ones between them.

Camera Scanning captures documents using the device camera. Edge Detection does the geometric work, using OpenCV and enhanced with a custom-trained machine learning model in ONNX format under an Apache 2.0 licence. Perspective Correction adjusts and crops documents with manual or automatic perspective correction, so a skewed photo can be straightened either automatically or by hand when the automatic result is wrong. Image Enhancement applies filters, with grayscale, contrast and sharpening among them.

OCR is offline text recognition, with PaddleOCR in the published paddle flavor. The OCR Review step is the one that distinguishes this from a scan-and-forget tool: it gives interactive review and correction of OCR results with word-level editing, dictionary-based suggestions, confidence highlighting and re-OCR for individual words.

That re-OCR for a single word is a design choice with real consequences. Rather than re-running the whole page, the app can reprocess one word, which is the difference between correcting a typo in a name in a contract in a few seconds and re-scanning the page. The confidence highlighting gives the same information passively, since a reviewer can see which words are uncertain without opening each one.

PDF Export is the last step, saving the result as a searchable PDF, which is the format that the downstream self-hosted tools consume.

The repository layout supports the claim that the OCR and detection models are first-class parts of the project rather than vendored binaries. There is a training/ directory, an ort/ directory for the ONNX Runtime work, an external/ directory, a third_party_licenses/ directory, a tools/ directory and a scripts/ directory, plus two test images at the top level named dewarp_test.jpg and dewarp_test_asymmetric.jpg, which look like fixtures for the perspective correction path.

There is also an ort/ directory alongside a .ort.yml file at the top level, which is the configuration for producing the operator-stripped ONNX Runtime build described in the editions section.

Where you can get it, and how to check what you got

The distribution channels are stated with unusual precision, and the reason is that an app with a searchable PDF pipeline is a plausible target for a repackaged copy with something else added.

The app is on F-Droid, on Google Play, and as an APK in the GitHub Releases section. The official app ID is de.schliweb.makeacopy, with de.schliweb.makeacopy.light for the Light edition. The readme is explicit that MakeACopy is only distributed via F-Droid, Google Play under this ID, and GitHub Releases of this repository, and that apps with the same name but a different package ID or developer are not affiliated with the project.

APK verification is documented with the actual fingerprints. All official releases are signed with one of two certificates. The upload key is used for GitHub releases, F-Droid and sideload APKs, and the Google Play App Signing key is used for Play Store releases, each with its SHA-256 fingerprint printed in the readme.

apksigner verify --print-certs MakeACopy-vX.Y.Z.apk

The check to run is that the printed certificate matches one of the two published SHA-256 values. If it does not, the file did not come from the project's own release process, whatever its name says.

The release history shows steady work. The recent releases are v4.7.2-rc1 on 2026-10-14, v4.7.1 on 2026-10-10 and v4.7.1-rc1 on 2026-10-04, and the last push was on 2026-10-14. The presence of release candidates alongside final builds suggests the maintainer ships a candidate first, which is useful to know if you are watching for a fix.

The repository also carries an AI_POLICY.md at the top level, alongside SECURITY.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, a NOTICE file, a HEADER file and a fastlane/ directory for store metadata, plus a metadata/ directory and a langpack-latin-best/ directory. The licence field recorded for the repository is a custom licence that GitHub cannot classify, with the terms in the LICENSE file, while a badge in the readme points at Apache 2.0. Both statements are there, so the licence to read before redistributing is the LICENSE file itself rather than either summary.

Where this sits against the cloud scanners and against doing it on the desktop

Two alternatives frame the decision, and each differs in where the work happens.

The first is a cloud scanner, which is what Microsoft Lens was and what most commercial document apps still are. The camera image is uploaded, OCR runs on a server, and the searchable PDF comes back. The advantages are a small download and, usually, better OCR on difficult pages, because the server can run bigger models than a phone will host. The cost is that the document leaves the device, which for a lease, a medical form or anything with a personal identifier means the document now exists on somebody else's hardware, and the retention policy of that service is not yours to set. MakeACopy's position is that this is unacceptable for the workflows it targets, and it accepts the size and the lower OCR quality as the price.

The second is scanning on a desktop with a flatbed or a phone camera and a local tool such as a Tesseract install plus a PDF assembler. The difference in approach is that the phone becomes a camera rather than the processing device. That gives you much more compute for the OCR and the image processing, and you can use a proper scanner, but the document still has to be moved off the phone somehow, which is where a cable, a cloud drive or a messaging app comes back in. The whole point of MakeACopy is to remove that step, and if your documents arrive by email rather than on paper, the offline premise does nothing for you.

Within the offline design there is a further comparison worth making, between the two OCR backends. PaddleOCR is the newer and generally stronger recogniser, and it is what the published build uses. Tesseract is the older engine, kept as a legacy flavor for people with existing Tesseract language data and workflows, which is a real migration path if you have trained data or a tuned configuration.

The self-hosted side is where MakeACopy does not compete at all. paperless-ngx does the filing, tagging and searching of documents after they arrive, and Syncthing moves files between machines. MakeACopy deliberately occupies only the first step, the capture and OCR, and hands off from there.

Editorial conclusion

MakeACopy fits a user who wants scanned documents to stay on the phone and land in a self-hosted archive such as paperless-ngx, and it does not fit someone who wants the smallest possible install, since the Full edition is about 99 MB for arm64-v8a because the OCR models ship inside the app. Before installing a build from outside the official channels, check the APK signing certificate with apksigner, because the project publishes the SHA-256 fingerprints of its upload key and its Google Play app signing key precisely so a repackaged app can be spotted.

Frequently asked questions

Official sources

1. egdels/makeacopy on GitHub
2. Issues
3. README
4. Releases