The @react-native-clipboard/clipboard package is the community-maintained, official replacement for React Native's removed built-in Clipboard API, and it is safe to use as long as you treat the clipboard itself as an untrusted, shared channel. The library is a thin native bridge; the real security questions are what you write into the clipboard and what you trust when you read it back.
This guide covers where the package came from, the risks specific to clipboard data on mobile, how to use getString and setString defensively, and basic supply-chain hygiene for the dependency.
Why This Package Exists
React Native's core Clipboard component was deprecated and then removed, and the community package took over. If you search for "react native clipboard" today, @react-native-clipboard/clipboard is the answer the ecosystem converged on. It succeeded the older @react-native-community/clipboard scope, so if you are on that name you are on an abandoned path and should migrate.
The API is small. It exposes methods to read and write text and provides a hook for reactive access.
import Clipboard from "@react-native-clipboard/clipboard";
// write
Clipboard.setString("some value");
// read
const copied = await Clipboard.getString();
Autolinking handles the native wiring on both platforms, so there is typically no manual linking step on current React Native versions.
The Clipboard Is a Shared, Untrusted Channel
The most important idea for anyone using clipboard react native APIs is that the system clipboard does not belong to your app. On both iOS and Android it is a shared surface. Other apps can read what you put there, and depending on the OS version and configuration, they may be able to do so in the background. That reality drives two distinct risks.
First, writing sensitive data leaks it. If you copy an auth token, a one-time passcode, a recovery phrase, or a password into the clipboard for convenience, any other app that reads the clipboard can capture it. This has been the basis of real-world credential-theft techniques against crypto wallet and banking apps.
Second, reading data trusts it. Content that arrives via getString() was placed there by something outside your control. If you paste it into a field and then use it as a URL, a deep link, or a command parameter, you are processing attacker-influenced input.
Using setString Safely
Treat setString as an action that publishes data to other apps, because that is what it does.
Do not copy secrets unless the user explicitly asked for it, and when you must, minimize the window. Modern OSes offer ways to mark clipboard content as sensitive so it is excluded from previews and cloud sync; use them where available, and clear the clipboard after a short delay when you have written something like a one-time code.
// Copy an OTP for the user, then clear it shortly after
Clipboard.setString(otp);
setTimeout(() => Clipboard.setString(""), 30000);
That is a mitigation, not a guarantee, since another app may have read the value already. The stronger control is simply not routing secrets through the clipboard when you can offer autofill or in-app entry instead.
Using getString Safely
When you read from the clipboard, validate before you act. The classic mobile bug is the "paste a link" flow that takes whatever is on the clipboard and opens it, turning a hostile clipboard entry into navigation to an attacker-controlled destination.
const raw = (await Clipboard.getString())?.trim();
// Validate scheme before treating pasted text as a URL
const ok = /^https:\/\//i.test(raw ?? "");
if (ok) openLink(raw);
The principle mirrors any input-validation problem: never assume the shape or intent of data you did not generate. Reject unexpected schemes, cap length, and do not interpolate pasted content into anything that gets evaluated.
Do Not Auto-Read on Launch
A pattern worth calling out: reading the clipboard automatically when the app foregrounds, to "helpfully" detect a copied code or link. iOS now surfaces a visible notification when an app reads the clipboard, and users reasonably read silent auto-reads as spying. Beyond the trust cost, it broadens your exposure to whatever hostile content happens to be sitting there. Read the clipboard in response to an explicit user action, not on every launch.
Dependency Hygiene
The package is a native module, which means it ships platform code that runs with your app's privileges. That is normal for React Native, but it is a reason to pin the version, review the changelog on upgrade, and pull it from a trustworthy source. Confirm the current release on the npm page for the package and keep an eye on the react-native-clipboard/clipboard repository for advisories.
npm ls @react-native-clipboard/clipboard
npm audit
Because native modules are harder to review than pure-JS packages, a build-time scan that tracks your full dependency tree is worth wiring into CI so you learn about an advisory in this or any other native bridge without watching each repo by hand. Our software composition analysis product covers that workflow.
FAQ
Is @react-native-clipboard/clipboard safe to use?
Yes. It is the community-maintained successor to React Native's removed clipboard API and has no widely cited vulnerabilities of its own. The risks live in how you use it: what you copy into the shared clipboard and how much you trust what you read back.
Should I use @react-native-community/clipboard instead?
No. That older scope is deprecated. @react-native-clipboard/clipboard is the maintained package the community moved to.
Can other apps read what my app copies with setString?
Yes. The system clipboard is shared across apps on both iOS and Android. Avoid copying secrets, mark sensitive content where the OS allows it, and clear short-lived values like one-time codes after use.
Is it safe to open a URL pasted from the clipboard?
Only after validation. Content from getString() is attacker-influenceable. Check the scheme, reject anything that is not an expected https link, and never pass pasted text into code that evaluates or executes it.