A password protected link controls entry to a download page. An encrypted file protects the file’s contents until someone decrypts it with the required key or password. They can be used together, but a password on a transfer page does not by itself establish that the file is encrypted from sender to recipient.
Both can present a password box, which makes them easy to confuse. The useful question is what happens after someone passes that box: do they receive an ordinary readable file, or an encrypted package they still need to unlock?
What does a password protected link protect?
A transfer password adds an access check before the recipient reaches the files. It is useful if a link reaches someone who does not also have the password.
HeftySend’s transfer password guide explains that the download page appears after the correct password is entered. This feature is available on Premium, Ultra and Lifetime. It is not included in the Free plan.
Someone who has both the link and the password can pass that check. Once an ordinary file has been downloaded, the transfer password is not a new password on the saved file. Treat those as two separate access decisions.
What does encrypting a file change?
File encryption changes readable contents into encrypted data that needs a key to be decrypted. In a password based archive, the software can derive that key from the password. The protection travels with that encrypted copy, rather than existing only on a website’s download page.
For example, the official 7z format documentation describes AES encryption and deriving a key from a user supplied password. Creating an archive and enabling encryption are separate choices: the file extension alone does not prove that encryption is enabled.
Agree a compatible tool and format with the recipient before delivering an encrypted package. They need to download it and decrypt it using the correct secret. Do not promise normal browser previews of the files locked inside it.
How is HTTPS different from file encryption?
HTTPS protects the connection between a browser and a website using TLS. It helps prevent someone monitoring that connection from reading the data travelling across it. It does not put a continuing password on a file saved to the recipient’s computer.
Cloudflare’s HTTPS explanation describes this transport protection. HeftySend’s security guide confirms HTTPS for uploads and downloads. Neither that statement nor the presence of a transfer password proves that only the sender and recipient hold the keys to the file’s contents.
Encryption from end to end means the sending and receiving endpoints can decrypt the content while the service carrying it cannot. The EFF guide to encryption explains why that differs from transport encryption. Do not infer this property from the word “secure” or a lock icon.
The educational video “The Internet: Encryption & Public Keys” introduces encryption, keys and secure web connections. Use it for those concepts; it is not a demonstration or audit of HeftySend.
Watch The Internet: Encryption and Public Keys on YouTube.
Which protection fits your delivery?
Choose according to what you need to protect and who needs to read the files. A page password can add a useful access check without giving the recipient a separate decryption task. A requirement to keep readable contents away from the delivery service needs a different assessment.
- You want an extra check if the link is forwarded: a transfer password can help, provided it is not forwarded with the link.
- You need the delivered package itself to remain encrypted: agree an appropriate file encryption workflow and how the recipient will obtain the secret.
- Your organisation specifies an approved system: follow that requirement. Do not replace it with a password protected link merely because both ask for a password.
- The client needs convenient previews: establish whether previewable files are appropriate for the material before choosing a separately encrypted package.
These are planning choices, not a claim that one setting makes every delivery suitable for confidential work. Ask the client which protection they require before assembling the package.
Can you use both a link password and an encrypted file?
Yes. The page password can control access to the transfer, while a separately encrypted file still needs decryption after download. Keep their purposes clear so the recipient knows which password belongs to which step.
Imagine a designer delivering public campaign images and a confidential planning document. This is an illustrative scenario, not a tested transfer. The client might accept a normal transfer for the images but require the document through its approved encrypted workflow. Separating those deliveries avoids giving everyone the confidential material merely because they need the images.
If the client approves an encrypted package on a transfer service, encrypt it before uploading, confirm that the selected delivery file is the encrypted copy and arrange the decryption secret through the agreed separate channel. Do not place the secret in the same delivery notes as the link. Ask the recipient to confirm that the intended files open after decryption.
What can HeftySend help with?
HeftySend handles the delivery link, supported file previews and collection experience. Free transfers currently allow up to 100 GB with three day expiry. Recipients do not need an account for normal downloads. Password protection and custom download pages require a paid plan; check the current plan comparison before choosing settings.
HeftySend has no bandwidth usage charges. If you connect your own storage, account for the storage provider’s charges separately. Paid custom download pages help present a delivery clearly, but branding does not replace access controls or file encryption.
Use the recipient instructions guide to explain the expected files, collection deadline and download steps. Keep the password or decryption secret out of screenshots sent for troubleshooting.
Frequently asked questions
Is every password protected ZIP equally secure?
No. The format, encryption method and password choice matter. Check the tool’s documented encryption settings and recipient compatibility rather than treating any password prompt as equivalent protection.
Does expiry remove files the recipient already saved?
No. Expiry controls availability through the transfer link. It does not erase a separately saved copy on the recipient’s device.
Can a recipient forward an encrypted file?
Yes. Encryption does not prevent copying the encrypted bytes. Someone who can decrypt the contents can also save or share a readable copy. Agree the permitted use with the recipient.
Does file encryption hide the filename?
Do not assume it does. Treat filenames, package titles and delivery messages as potentially visible unless the chosen tool explicitly protects them. Avoid putting sensitive details in those labels.
Is account login the same as a transfer password?
No. Account login controls access to your account. A transfer password is a separate check on a particular delivery page. HeftySend’s account login uses an email magic link or code; that does not mean every transfer has a password.
What if the recipient cannot decrypt the package?
Confirm the agreed format, application and secret through the intended channel. Keep the original files and a secure record of the required secret according to your delivery arrangements. Do not promise that the transfer service can recover a password for a file encrypted elsewhere.
Start with the client’s actual requirements, then choose the delivery and protection together. Clear instructions help the recipient understand whether they are opening a protected page, decrypting a file, or doing both.
Product guidance checked on 28 October 2026. The example is illustrative. No test transfer or security audit was performed.