FreeOTP Plus is a rewritten Android authenticator with export and locking
Enhanced fork of FreeOTP-Android providing a feature-rich 2FA authenticator
At a glance
- What is it?
- FreeOTP Plus is a fork of Red Hat's FreeOTP-Android that keeps the same two factor token handling but rewrites most of the code in Kotlin with modern Jetpack libraries. The additions that matter in practice are settings export to any document provider, biometric or PIN locking at launch, token categories, offline icons for 250 or more sites and a faster QR scan path.
- Who is it for?
- Android users who need to move authenticator tokens between devices or keep a backup, or who want their second factor app locked behind a biometric, should use FreeOTP Plus, because it keeps the FreeOTP token format while adding document provider export and import, categories, offline site icons and a Material 3 interface.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 60 days ago.
- What is it written in?
- Mainly Kotlin, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 22, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The same tokens, a different codebase
FreeOTP Plus forked the same functionality of FreeOTP, the authenticator provided by Red Hat, and added a list of enhancements on top of it.
The key sentence is the last one in the README's introduction: most part of the code is re-written with modern Jetpack libraries and Kotlin language. The primary language of the repository is Kotlin, and the top level shows a normal modern Android project with build.gradle.kts and settings.gradle.kts written in Kotlin DSL, a gradle directory, the gradlew and gradlew.bat wrappers, an app module, an arts directory and a scripts directory.
That distinction matters more than the usual fork arithmetic. A fork that keeps the upstream code keeps the upstream maintenance burden and the upstream language, and the interesting question for an adopter is whether the fork has genuinely diverged. Here the answer is yes: this is a rewrite of most of the code rather than a set of patches on top of it, with Jetpack replacing the older Android support libraries.
The enhancement list is the best available statement of the fork's purpose. Export settings to Google Drive or other document providers. Import settings from Google Drive or other document providers. Lots of stability improvement. Support for Android 6.0 permissions. An enhanced user interface with material design v3 and dark theme support. A search bar to search tokens. More token details for better interoperability with other apps. Use of modern camera hardware to scan QR codes faster. An option to require biometric or PIN authentication to launch the app. A heuristic based offline icon for tokens of 250 or more websites. The ability to categorize tokens and filter by category. And more settings to customize the app functionality.
Read together, those point at one recurring theme. The upstream authenticator is a minimal token list, and this fork is an attempt at a fuller one, with the export and import pair being the feature that changes how you use it most.
Export and import through document providers, not a proprietary cloud
The export and import pair deserves the most attention, because it is the one feature that changes what happens when you lose your phone.
The wording matters. Settings are exported to Google Drive or other document providers, and imported from Google Drive or other document providers. Google Drive is named as the common case, but the mechanism is the Android document provider interface, so any app that exposes files through that interface works as a backup target. That is a meaningfully different design from a tool that ships its own sync account or its own server, and it has a practical consequence: the backup location is something the user already has, and the app does not need credentials for a vendor service.
The other half of the story is that import is strict, and the README is unusually blunt about how it fails. When importing from JSON, both issuerExt and label are required, and if missing the entry will be silently ignored. The secret is required and needs to be an array or list of unsigned char integer values. And tokenOrder is required, with any tokens not listed silently ignored.
Silently ignored is the operative phrase, and it applies twice. An entry with a missing field disappears, and so does an entry whose position is not in the order list. A user who exports from one device, edits the JSON by hand, and imports on another can lose tokens without any error message. The required fields, issuerExt, label and the secret as integer values, plus the tokenOrder list, are the ones to check first when an import comes back short.
That combination, a portable backup and a strict importer, is the trade this fork makes. The backup is easy to take and easy to move, and the file format is strict enough that a malformed entry disappears rather than erroring.
Locking the app, and the offline icon trick
Two features here are about behaviour on a physical device rather than about token formats.
The first is the option to require biometric or PIN authentication to launch the app. On an authenticator, the threat model is specific: the codes themselves are time based, so a person who can open the phone and read the screen can generate a valid code. Locking the app does not change that fundamental property, but it does add a step between a stolen or borrowed phone and a usable second factor, and it removes the case where the app is open on a screen someone else can see.
The second is the heuristic based offline icon for tokens of 250 or more websites. The word offline is doing the work here. The icon for a token is derived from a heuristic, from the issuer or domain in the token's metadata, against a table of known sites, and it is computed on the device rather than fetched. That means no network request per token and no dependency on a favicon service being reachable, which for a security application is a reasonable default. The cost is that the heuristic is a heuristic: sites that are not in the table fall back to something generic.
The related feature is more token details for better interoperability with other apps, which suggests the token records carry more metadata than the upstream format did. Token categories with filtering by category are the companion to that, and the search bar to search tokens completes the navigation story: instead of a flat scrolling list, tokens are grouped and searchable.
The remaining entries are quality of life rather than policy. Material design v3 with dark theme support changes the look of the app. Support for Android 6.0 permissions matters on devices that predate the runtime permission model in its current form. Lots of stability improvement is not a specification, but on an authenticator, crashes and lost tokens are the failure that matters most. And using modern camera hardware to scan QR codes faster is a real gain, since adding a token is the most frequent action in the app.
Getting it: three distribution channels, Android 5.0 and newer
The README links three ways to obtain the app, and they differ in more than the download button.
There is an F-Droid listing for the package org.liberty.android.freeotpplus. There is a Google Play listing for the same package id, org.liberty.android.freeotpplus. And there is a GitHub releases page pointing at the latest release.
For the F-Droid and Play channels, the build is produced by the project's own release process. For GitHub, the README links to the releases/latest tag, and the release names in the repository record follow the pattern RELEASE-3.4, RELEASE-3.3 and RELEASE-3.2, which tells you that releases are cut from this repository rather than mirrored from a store.
The runtime requirement is Android 5.0 or newer, and the build dependencies are the Android SDK and Android Studio 4.0 or later. There is no command line build sequence in the README to copy, so building from source means opening the project in Android Studio and using the Gradle wrappers that ship in the repository.
The repository layout shows how a release is packaged. There is a fastlane directory, which is the standard toolchain for the store metadata and screenshots, and its metadata directory holds the phone screenshots that the README shows. There is a scripts directory and an arts directory for artwork, and the token imagery lives in token-images and token-data, with text-drawable holding vector assets. There is also a crowdin.example.yml, which is the configuration template for the translation workflow described in the README.
That last point has a direct consequence for contributors. Translations are managed through Crowdin, with a project link given in the README, and the README says that if your language is not listed you should open an issue so it can be added, while contributors who prefer not to use Crowdin can submit a pull request with updated or added locales.
Where FreeOTP Plus is the wrong tool
The limits are clear and mostly follow from what a software authenticator is.
It is Android only. There is no iOS build and no desktop build, so a workflow that spans a phone and a laptop authenticator needs a second tool, and moving tokens between them means the export and import path rather than a shared account.
It is a software authenticator. It generates TOTP and HOTP codes on the device, and the repository topics name both. There is no support for hardware security keys, which is a deliberate trade most people make once, but an organisation with a policy requiring phishing-resistant factors will not accept it. The optional biometric lock is a gate on the app, not a hardware-backed key.
The import path is the sharpest edge. Entries missing issuerExt, label, secret or a position in tokenOrder are silently ignored, so a partially correct file produces a partially imported account rather than an error. If you are migrating from another authenticator and count matters, check the number of tokens before and after.
The offline icon heuristic has the corresponding weakness. It works for the sites it knows about, and the README says 250 or more websites, and falls back for the rest. Nothing breaks, but the icons are inconsistent in a way that is easy to mistake for a bug.
And the export target depends on the device having a document provider app configured for Google Drive or another provider. On a device with no such app, the feature has nowhere to write.
Licence, icons and the release cadence
The licence is Apache-2.0, which is what you would expect for a fork of a Red Hat project and is permissive enough for redistribution in an internal build. There are two licence files at the root, COPYING and COPYING.icons, and the second one is the one to look at carefully: the icon set is licensed separately from the code, so the terms for the artwork are not necessarily the same as the terms for the application.
That matters for this project in particular, because the token imagery for 250 or more websites is part of the user interface. If you are packaging the app for an organisation, the icon licensing is the piece that needs a separate look, and the README does not summarise it for you.
On maintenance, the release record is steady. The recent releases are RELEASE-3.2 on 2026-03-24, RELEASE-3.3 on 2026-05-19 and RELEASE-3.4 on 2026-05-31. The last push was on 2026-08-24 and the repository is not archived, so commits are landing on the master branch between tagged releases.
The upgrade cost for an end user is the one that matters, and it is not the code. Tokens live in the app's own storage, so an update does not touch them. What does change is the import and export format expectations as the fork adds token detail fields, and the permission model on older Android versions. If you keep an exported JSON backup, the sensible habit is to re-export after an update rather than assume an old backup still parses.
The community side is documented: the README points at the Crowdin project for translation work and invites pull requests for updated or added locales.
Editorial conclusion
Android users who need to move authenticator tokens between devices or keep a backup, or who want their second factor app locked behind a biometric, should use FreeOTP Plus, because it keeps the FreeOTP token format while adding document provider export and import, categories, offline site icons and a Material 3 interface. It is the wrong tool on iOS, since the project is Android only, and it is the wrong tool for anyone whose accounts depend on hardware security keys, because it is a software authenticator with no hardware key support. Before migrating, read the import requirements carefully, since entries missing issuerExt, label, secret or tokenOrder are silently ignored, and check the release tags, where the current tagged build is RELEASE-3.4 from 2026-05-31.
Frequently asked questions
What is the difference between FreeOTP Plus and Red Hat's FreeOTP?
FreeOTP Plus forked the same functionality of FreeOTP provided by Red Hat, and most of the code has been re-written with modern Jetpack libraries and Kotlin. The additions include export and import of settings through Google Drive or other document providers, biometric or PIN locking at launch, token categories, a search bar, offline icons for 250 or more sites and a Material 3 interface.
How do I install FreeOTP Plus?
The README links three channels: an F-Droid listing, a Google Play listing, both under the package id org.liberty.android.freeotpplus, and the GitHub releases page. The app requires Android 5.0 or newer, and building from source requires the Android SDK and Android Studio 4.0 or later.
Why are some tokens missing after I import a JSON backup?
Both issuerExt and label are required, the secret is required and must be an array or list of unsigned char integer values, and tokenOrder is required with any tokens not listed silently ignored. Entries that fail those rules are silently ignored rather than reported as errors.
Does FreeOTP Plus need network access to show token icons?
The README describes a heuristic based offline icon for tokens of 250 or more websites, so the icons are derived on the device rather than downloaded. Sites outside that set fall back to a generic icon.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/helloworld1-freeotpplus)Was this useful?