Privacy Policy
Privacy-first secret sharing, explained plainly.
iKrypt is built so the server does not receive your plaintext secret or your decryption key. This policy explains what we can access, what we store, what third parties we use, and where the limits are.
Last updated: July 2026
We cannot read your secrets
Secrets are encrypted in your browser before upload. iKrypt stores encrypted ciphertext, not plaintext.
The key stays client-side
The decryption key is placed in the URL fragment after # and is not sent to iKrypt servers in normal requests.
No account required
You can create a one-time encrypted secret link without signing up or creating a profile.
Our privacy model
iKrypt uses a zero-knowledge-style architecture for secret sharing. When you paste a secret, it is encrypted in your browser before upload. The server receives encrypted ciphertext, not the plaintext content.
The decryption key is placed in the URL fragment, which is the part of the link after the # symbol. Browsers do not send URL fragments to servers in normal HTTP requests, so iKrypt does not receive that key.
This design protects your secret from being stored as readable text on iKrypt servers. It does not protect against compromised devices, malicious browser extensions, or someone forwarding the full link including the fragment key.
What we cannot access
- The plaintext content of your secret
- The decryption key in the URL fragment
- The decrypted content shown to the recipient
- A user account profile, because no account is required
What we store
For secret links, iKrypt stores the minimum data needed to deliver the encrypted secret and enforce expiry or view limits.
- Encrypted ciphertext
- Initialization vector, also called IV
- Creation time
- Expiry time
- Current view count
- Maximum allowed views
- Optional notification email, only if you choose to provide one
We do not store the plaintext secret or the decryption key. Optional notification emails are used only for the notification feature and are tied to the lifecycle of the secret.
Deletion and expiry
Encrypted secrets become inaccessible when one of these happens:
- The maximum view count is reached.
- The expiration time passes.
- The record is no longer available.
Once a secret becomes inaccessible, the API will not return its encrypted contents again. Access is blocked immediately when the expiry or view-limit condition is met.
When the final allowed view is consumed, the encrypted record is deleted as part of that server-side transaction. For secrets that expire without being viewed, the encrypted record is removed automatically by a Firestore TTL policy, typically within 24 hours of expiry.
Analytics and scripts
The pages where secrets are created or viewed do not load third-party analytics scripts. That includes the homepage secret form and individual secret viewing pages.
Public marketing and content pages may use limited aggregate analytics, such as Ahrefs Analytics, to understand traffic patterns. We do not link analytics data to individual secret contents.
Hosting providers and infrastructure services may also process standard request information, such as IP address, user agent, request path, and timestamps, as part of operating and protecting the service.
Rate limiting and abuse prevention
To prevent abuse, spam, and automated misuse, iKrypt may process request metadata such as IP address or a hashed/derived identifier for rate limiting. This data is used for security and abuse prevention and is not linked to the plaintext content of secrets, which we cannot access.
Email notifications
If you choose to provide an email address for view notifications, we use it only to notify you when the secret link is accessed.
We do not add notification emails to marketing lists. We do not sell or share them for advertising. Notification emails are deleted or become unavailable according to the lifecycle of the associated secret.
A notification means the link was accessed. It does not guarantee that a specific human read the secret, because link scanners or automated tools may sometimes access links.
Contact forms
If you contact us through the contact page, the information you submit is processed by Formspree and sent to us so we can respond.
Do not include passwords, API keys, private keys, recovery codes, or other secrets in the contact form. Use iKrypt itself to create a one-time encrypted link when you need to share a secret.
Third-party services
iKrypt uses third-party infrastructure providers to operate the service:
Firebase / Firestore
Stores encrypted ciphertext and related metadata for secret links.
Vercel
Provides hosting, CDN, edge caching, and server-side infrastructure for the website and API routes.
Upstash
Supports rate limiting and abuse prevention.
Resend
Sends optional view-notification emails when you provide an email address.
Formspree
Handles messages submitted through the contact form.
Ahrefs Analytics
May be used on public marketing/content pages for aggregate traffic analytics. It is not loaded on secret creation or secret viewing pages.
Your rights and choices
Because iKrypt does not require accounts and cannot read secret contents, we may not be able to identify which encrypted secret belongs to you unless you provide the exact secret link or related context.
The easiest way to remove a secret is to set a short expiry or one-view limit when creating it. After expiry or final view, the secret becomes inaccessible, and the encrypted record is removed according to the deletion behavior described above.
For privacy-related requests or questions, contact us using the details below.
Changes to this policy
We may update this Privacy Policy from time to time as iKrypt changes. When we make meaningful changes, we will update the “Last updated” date and, where appropriate, add a notice on the website.
Contact
For privacy-related questions, contact us at write@digiwares.xyz or use the contact page.