सादा टेक्स्ट

Web Crypto API के माध्यम से AES-256-GCM का उपयोग करता है। प्रत्येक एन्क्रिप्शन पर एक यादृच्छिक 96-बिट IV और 128-बिट सॉल्ट जनरेट होता है।

कैसे उपयोग करें

1. एन्क्रिप्ट या डिक्रिप्ट मोड चुनें।
2. अपना टेक्स्ट और एक पासवर्ड दर्ज करें।
3. क्रिया बटन पर क्लिक करें · परिणाम नीचे प्रकट होता है।
4. डिक्रिप्ट करने के लिए, एन्क्रिप्टेड आउटपुट पेस्ट करें और वही पासवर्ड उपयोग करें।

अक्सर पूछे जाने वाले प्रश्न

क्या यह एन्क्रिप्शन सुरक्षित है?

हाँ। AES-256-GCM सैन्य-ग्रेड एन्क्रिप्शन है। PBKDF2 कुंजी व्युत्पत्ति (100k पुनरावृत्तियाँ) के साथ, यह मज़बूत सुरक्षा प्रदान करता है।

क्या आप मेरा पासवर्ड पुनर्प्राप्त कर सकते हैं?

नहीं। सब कुछ आपके ब्राउज़र में चलता है। हम कभी आपका टेक्स्ट या पासवर्ड नहीं देखते। यदि आप अपना पासवर्ड खो देते हैं, तो टेक्स्ट वापस नहीं मिलेगा।

आउटपुट का प्रारूप क्या है?

एन्क्रिप्टेड आउटपुट Base64 स्ट्रिंग है जिसमें सॉल्ट, IV और सिफ़र टेक्स्ट शामिल है। डिक्रिप्ट करने के लिए इसे बस टूल में वापस पेस्ट करें।

What's actually happening when you click Encrypt

Symmetric ciphers like AES use the same key to encrypt and decrypt. That means whoever holds the key can both lock and unlock the data, so the entire challenge of using one collapses to a single question: how do the sender and recipient share the key without leaking it? This tool's answer is "you handle that yourself", agree on a password through a separate trusted channel, then both of you paste the same string here.

Behind the scenes the tool runs four steps via the browser's native Web Crypto API:

1. Stretch your password into a key. A password is a short, low-entropy string; an AES-256 key is 32 bytes of high-entropy random data. The tool feeds your password through PBKDF2-HMAC-SHA-256 with 100,000 iterations (specified in RFC 8018) plus a 128-bit random salt. The salt makes every encryption produce a different key even if you reuse the password, killing rainbow-table attacks. The iteration count slows down brute-force guessing on a per-attempt basis.
2. Generate a fresh nonce. A 96-bit random IV (the NIST-recommended length for AES-GCM) is created via crypto.getRandomValues: the same cryptographically secure randomness source the browser uses for TLS.
3. Encrypt with AES-256-GCM. The plaintext is encoded as UTF-8 bytes and passed through AES-256 in Galois/Counter Mode, which produces ciphertext plus a 128-bit authentication tag.
4. Package and Base64-encode. The salt, the IV, and the ciphertext+tag are concatenated into a single binary blob and Base64-encoded so it travels safely through email, chat, or anywhere else that expects ASCII.

Why AES-256-GCM specifically

AES (Advanced Encryption Standard) is the symmetric cipher NIST chose in 2000 from a public competition with 15 candidates. The winning design was Rijndael by the Belgian cryptographers Joan Daemen and Vincent Rijmen, formalised as FIPS PUB 197 on 26 November 2001. NIST approves three key sizes (128, 192, 256 bits) and the NSA approves all three for SECRET data, with AES-256 also approved for TOP SECRET. After more than two decades of public scrutiny there is still no practical attack against properly implemented AES, the cipher itself is essentially unbreakable, so the security argument shifts entirely to key management and password strength.

A block cipher like AES only encrypts one fixed-size 128-bit block, so any real message needs a mode of operation to glue blocks together. The mode matters as much as the cipher. The notorious old default, ECB: encrypts each block independently, which leaks patterns; the famous "ECB Penguin" image of Tux still recognisable after encryption is the standard cautionary illustration. Many older online "AES" tools still expose ECB; this one does not.

GCM (Galois/Counter Mode), designed by McGrew and Viega and standardised by NIST in SP 800-38D (November 2007), combines counter-mode encryption with a Galois-field authentication tag. It's an AEAD mode (Authenticated Encryption with Associated Data) meaning it provides confidentiality and integrity in one operation. If a single byte of the encrypted output is flipped, decryption raises an error rather than returning garbled plaintext. Same mode TLS 1.2 and TLS 1.3 use. It is genuinely the workhorse mode of modern internet cryptography.

A password is not a key

An AES-256 key is 32 bytes of uniform randomness. A user's password (even a strong one) is short, mostly printable ASCII, and clusters around dictionary patterns. You can't feed a password directly into AES without help. That help is a password-based key derivation function (KDF). PBKDF2, scrypt, and Argon2 are the three you'll see in modern code:

• PBKDF2 (RFC 8018), the original. Iterates an HMAC pseudo-random function many times. Fast on a CPU, but not memory-hard: GPUs and ASICs crack PBKDF2 hashes much faster than the iteration count would suggest on a normal computer. This tool uses PBKDF2 because it's the only password KDF that the Web Crypto API exposes natively, Argon2 and scrypt would require shipping extra JavaScript or WebAssembly.
• scrypt (RFC 7914, 2016, by Colin Percival)) added memory-hardness: forces an attacker to allocate a large block of RAM per guess, defeating cheap parallel hardware.
• Argon2id (RFC 9106, 2021), winner of the 2015 Password Hashing Competition; OWASP's current first-choice recommendation. Memory-hard, side-channel resistant.

Honest caveat: 100,000 PBKDF2 iterations is well above the original RFC floor of 1,000, but below OWASP's current 2026 guidance of 600,000 for PBKDF2-SHA-256. The trade-off is encryption time on slow phones, at 600,000 iterations, deriving a key on a budget Android device starts to add a noticeable pause. For high-stakes long-term secrets, choose a longer password to compensate, or use a dedicated password manager which typically uses Argon2id with stronger parameters.

Salt and IV, they look similar, they do different things

• Salt is input to the key derivation. It makes the password→key mapping unique per encryption, so a stolen ciphertext can't be cracked using a precomputed table of common-password keys. Salt doesn't have to be secret, just unique and unpredictable.
• IV / nonce is input to the cipher mode. For AES-GCM specifically, it's the 96-bit counter starting point. It must be unique per (key, message) pair; reusing one is catastrophic in GCM, it lets an attacker recover the GHASH key and forge arbitrary ciphertexts. The tool generates a fresh random IV from crypto.getRandomValues every encryption, which avoids that risk.

When to use this, and when not to

The right tool when:

• You need to share a single secret message via an untrusted channel (email, Slack, SMS, a notes app) and you have a separate trusted channel (a phone call, a face-to-face meeting, a Signal chat) where you can hand over the password.
• You want to encrypt a snippet locally before pasting it into a cloud document or note-taking app, so even if the provider is breached the contents are unreadable.
• You need a "sealed envelope" attached to a workflow with a partner who's agreed on a password verbally.

The wrong tool when:

• You and your recipient have no pre-shared secret and no out-of-band channel. Sending the password via the same channel as the ciphertext is pointless, anyone who can read the ciphertext can read the password too. This is the classic chicken-and-egg key-distribution problem that public-key crypto exists to solve.
• You need forward secrecy. Signal and TLS 1.3 produce a different ephemeral key for every session, so a leak today doesn't expose past messages. A single fixed password gives the opposite property: anyone who learns the password can decrypt every message you ever encrypted with it.
• You need to prove who encrypted something. AES with a shared password proves possession of the password, not authorship. For digital signatures use PGP, age, or S/MIME.
• You're encrypting at scale or for many recipients. Every recipient needs a separately shared password and rotation is painful. Asymmetric tools (age, PGP) and Signal-style key servers handle this better.

A useful mental model: AES with a password is the digital equivalent of a luggage padlock combined with a phone call to share the combination. It works perfectly if you can trust the phone call. It is not a substitute for end-to-end-encrypted messaging like Signal, which automates the key exchange and provides forward secrecy through its Double Ratchet protocol.

How strong is "strong enough" for the password?

Because the cipher itself is unbreakable, the entire security of the scheme rests on your password. The relevant math is entropy: H = L × log₂(N), where L is length and N is the size of the character set you're drawing from at random. Worked examples:

• 8 random lowercase letters → about 37 bits. Crackable in hours on a modern GPU.
• 8 mixed-case characters with digits and symbols → about 52 bits. Hours to days at modern speeds.
• 12 mixed-case characters with digits and symbols → about 79 bits. Beyond practical attack budgets for the foreseeable future.
• Six random words from a 7,776-word Diceware list → about 78 bits. Roughly the same security as 12 random characters but vastly easier to memorise.

Human-chosen passwords are dramatically weaker: research cited in NIST guidance estimates the average at around 40 bits, which is why dictionary attacks dominate over pure brute force. NIST SP 800-63B's current advice for memorised secrets: minimum 8 characters, allow at least 64, don't impose composition rules (they push users toward predictable patterns like Password1!), don't require periodic rotation, and screen against lists of known-breached passwords. Aim for "long, memorable, never been in a breach." A four-to-six word random passphrase you can actually remember beats a tortured 8-character "complex" password every time.

Where it sits next to other encryption tools

• TLS / HTTPS encrypts in transit between you and a server. The server itself can read everything once it lands. Solves the eavesdropper problem, not the server problem.
• Signal / WhatsApp / iMessage are full end-to-end encryption with automatic key exchange and forward secrecy. Solve both, but require both parties to use the same app.
• PGP / age are asymmetric, you encrypt to someone's published public key without needing a shared secret first. Solves key distribution, but historically painful to use; age is the modern minimalist alternative.
• OS-level disk encryption (FileVault, BitLocker, LUKS) encrypts data at rest on a single device using AES-XTS. Different threat model: protects against device theft, not against network interception.
• Password managers use AES-GCM (or similar) with strong KDFs (typically Argon2id today) inside an encrypted vault that syncs ciphertext through a vendor backend that cannot read it.

A password-based text encryptor is the least specialised member of this family, pure cryptography with no opinion on identity, transport, or storage. That minimalism is the appeal: it's the right tool when you specifically need just AES-256 with a password and nothing else.

More questions

Is this end-to-end encrypted?

In one sense yes, the encryption happens entirely in your browser and Absolutool never sees the plaintext or the password. In the strict sense that messaging products like Signal use, no: Signal additionally provides automatic asymmetric key exchange and identity binding so users don't need a separate trusted channel to share a password. This tool does the encryption half without those extras, which is what makes the password-handoff your responsibility.

Is there a "forgot password" recovery?

No, by design. The tool never sees your password and never stores anything. If you lose the password the encrypted text is unrecoverable. Save the password in a password manager or write it down somewhere physical.

Why does the encrypted output look like random Base64?

Because that's exactly what it is. The salt, the IV, and the ciphertext-plus-authentication-tag are concatenated into a single binary blob and Base64-encoded so the result travels safely through systems that expect printable ASCII (email, JSON, query strings). All three components are needed at decryption time, which is why they're packaged together, the tool re-extracts them when you paste the blob back in.

Is AES-256 illegal anywhere?

Mass-market cryptography is broadly legal in essentially every consumer-facing product worldwide as of 2026. The US Crypto Wars of the 1990s ended with Executive Order 13026 (1996) and the 2000 mass-market relaxation. Specific embargoed destinations (Iran, North Korea, Syria, Cuba) and a handful of countries with their own import or use restrictions on strong cryptography (China, Russia, Vietnam and Saudi Arabia among them) are still worth checking against local law if you're using the tool in those jurisdictions.

Does anything get sent to a server?

No. The Web Crypto API runs natively in the browser; crypto.subtle calls into the same crypto library the browser uses for TLS (BoringSSL on Chrome, NSS on Firefox, CommonCrypto on Safari). Nothing leaves your device. The page also requires HTTPS, which is enforced by the browser, Web Crypto is only available on secure contexts to prevent a network attacker from swapping the JavaScript before it runs.

संबंधित टूल