How form data travels securely: HTTPS, TLS and encryption

When a customer types their phone number into your enquiry form and taps submit, that text crosses a mobile tower, an internet provider's network and several routers before reaching your server. Anyone sitting on that path can read it unless the connection is encrypted. This article explains, without jargon, how HTTPS protects form data as it travels, what TLS is actually doing, which settings matter on your own site, and what changes when your form is handled by someone else's service.

You do not need to configure TLS by hand to run a website, but you do need to know enough to tell whether yours is set up properly and to ask your host the right questions.

What happens between tapping submit and the data arriving

Over plain HTTP, the browser packages your form fields into a request and sends them as readable text. Over HTTPS, the same request is wrapped inside an encrypted channel that was negotiated before any of your data moved.

The negotiation, called the TLS handshake, does three things. It authenticates the server by presenting a certificate that a trusted authority has signed for your domain, so the browser knows it is talking to the real site. It agrees keys for this session using public key cryptography, without ever sending the secret itself across the wire. And it switches to fast symmetric encryption for the actual data.

The result gives you three properties: confidentiality, so nobody along the path can read the values; integrity, so nobody can quietly alter them; and authentication of the server. It does not encrypt where the request is going, since the domain name is visible to the network, and it says nothing about what happens to the data once it lands.

POST is not more secure than GET

A persistent myth deserves correcting. Using POST rather than GET does not encrypt anything. On plain HTTP, POST bodies are just as readable as a query string.

POST is still the right choice for forms, for a different reason: values in a URL end up in browser history, server access logs, referrer headers sent to third parties, and any link the customer copies and shares. So use POST for anything personal, and use HTTPS to make it private. They solve separate problems.

Certificates and TLS versions worth knowing about

Which certificate do you need?

For almost every business site, a standard domain-validated certificate is sufficient, and Let's Encrypt issues them free with automatic renewal. Extended validation certificates cost more and no longer produce a distinctive browser display, so the security benefit is limited. What matters far more is that the certificate covers every hostname you use, including the www and non-www versions, and that it renews automatically before expiry.

Which TLS versions?

TLS 1.2 and TLS 1.3 are the current versions. TLS 1.0 and 1.1 are deprecated and browsers have removed support; SSL 2 and 3 have been broken for years. If your hosting still offers them, ask for them to be disabled. TLS 1.3 also completes its handshake in fewer round trips, which is noticeably faster on mobile networks.

Redirects and HSTS

Having a certificate is not enough if the site still answers on HTTP. Redirect all HTTP traffic to HTTPS with a 301, then consider adding an HSTS header, which tells browsers to use HTTPS for your domain automatically for a set period. Start with a short max-age while you confirm every subdomain works over HTTPS, because HSTS is difficult to reverse quickly.

The mistakes that quietly break encryption

• A form on an HTTP page posting to an HTTPS URL. The submission itself is encrypted, but the page delivering the form was not, so an attacker on the network could have altered where it posts. Browsers now warn about this.
• Mixed content: an HTTPS page loading scripts, stylesheets or images over HTTP. Scripts are the dangerous case, since a modified script can read everything the user types. Check the browser console for mixed content warnings.
• An expired certificate. Visitors get a full-page warning and most will leave. Automate renewal and add an external monitor that alerts you a couple of weeks before expiry.
• A certificate that does not cover the hostname used, so www works and the bare domain shows an error, or vice versa.
• Encryption ending at a proxy. If a CDN terminates TLS and then talks to your origin server over plain HTTP, that final hop is exposed. Use a secure connection between the CDN and the origin.
• Missing cookie flags. Session cookies without the Secure and HttpOnly attributes can leak, undermining the protection the connection provides.

When someone else handles your form

Plenty of sites post enquiries to an external form service, a marketing platform or an embedded widget. That is not automatically wrong, but the data now travels to and sits on a system you do not administer, so ask a few questions.

1. Is the endpoint HTTPS, and is the embedded script also loaded over HTTPS from a domain you recognise?
2. Where is the data stored, in which country, and for how long?
3. Who on your side can access it, and can you remove a person's access when they leave?
4. Does the service email submissions onward in plain text, which reintroduces the exposure you were avoiding?
5. Can you export and delete records when a customer asks you to?
6. What is in their processing terms, particularly around subcontractors and breach notification?

Under India's DPDP Act 2023 the responsibility for personal data you collect generally stays with you even when a vendor processes it, so treat the choice of form provider as a decision about your own obligations. For specifics about your situation, confirm with a qualified professional.

Check your own site in ten minutes

Open your form page and work through this list. Is the padlock present on the page that contains the form, not only on the page after it? Does typing the HTTP address redirect you to HTTPS? Does the browser console show mixed content warnings? Does an online SSL test report TLS 1.2 or 1.3 only, with a valid chain? Does the certificate expiry date sit comfortably in the future, and is renewal automatic?

Anything that fails is usually a hosting or configuration change rather than a rewrite. If you would rather have certificates, redirects and TLS settings handled for you, they come configured as part of our Linux hosting plans.

Frequently asked questions

Does HTTPS slow down my website?

Not meaningfully on modern hardware. TLS 1.3 needs fewer round trips than older versions, and HTTPS is required for HTTP/2 and HTTP/3, which usually make a site faster overall.

Is a free certificate less secure than a paid one?

The encryption is identical. Paid certificates differ in validation level, warranty and support, not in the strength of the connection. A free certificate that renews automatically is safer in practice than a paid one somebody forgets to renew.

Does the padlock mean the website is trustworthy?

No. It means the connection is encrypted and the certificate matches the domain. Fraudulent sites can obtain certificates too, so the padlock proves privacy in transit, not honesty.

Is data safe once it reaches my server?

That is a separate question. TLS protects the journey only. Storage encryption, access control, backups and how long you keep records all need their own attention.