Some modern browser APIs (service workers, certain geolocation and media features) specifically require a "secure context" — HTTPS, or the special-cased localhost exception — which means local development sometimes genuinely needs working HTTPS, not just as a nice-to-have.
The simplest path: mkcert
The mkcert tool is purpose-built for exactly this: it creates a local certificate authority, installs it in your system's trust store, and issues certificates for localhost or any custom local domain you're using, all trusted by your browser with no manual warnings to click through.
Framework-specific dev servers
Many modern dev server tools (Vite, Create React App via a plugin, and others) have built-in flags or plugins to serve over HTTPS directly, often integrating with mkcert-generated certificates automatically — worth checking your specific tool's documentation rather than manually configuring a full web server just for local development.
What to do if your local HTTPS setup works in one browser but not another
Different browsers maintain independent trust stores in some cases, meaning a locally-trusted certificate added to one browser's trust may not automatically be trusted by another — confirming the certificate was added to each browser's relevant trust store, or using a tool like mkcert that handles this more comprehensively, resolves cross-browser inconsistency.
How to handle HTTPS for a local API that a mobile app or another device needs to reach
For a local API that needs to be reached by a physical mobile device rather than just your development machine's own browser, using your machine's local network IP address with a certificate covering that IP (or a local domain name resolved via your hosts file or local DNS) lets the mobile device establish a trusted HTTPS connection during development.
What the difference is between trusting a certificate at the OS level versus the browser level
Some browsers (particularly Firefox, in some configurations) maintain their own independent certificate trust store rather than relying on the operating system's — trusting a certificate at the OS level alone doesn't guarantee every browser will automatically trust it too.
How Docker-based local development environments handle HTTPS differently
A containerized local development environment often runs a reverse proxy container (Traefik or Nginx) handling local HTTPS termination for multiple services simultaneously, following a similar pattern to the Docker TLS setup covered in our How-To deep-dive on containerized applications.
Why some teams standardize on a shared local CA rather than individual self-signed certificates
A shared local CA (installed once on every team member's machine) lets everyone trust locally-issued certificates consistently without each person maintaining separate self-signed certificates and separate trust exceptions — a more scalable approach for a team than each developer managing their own individual setup.
What to do if your local HTTPS setup breaks after a system or browser update
A system or browser update occasionally resets or invalidates previously trusted local certificates — re-running your certificate trust setup (mkcert's install command, for instance) after a major OS or browser update is a reasonable troubleshooting first step if local HTTPS suddenly stops working without any change on your part.
How to handle local HTTPS for a project with multiple services each needing their own domain
For a local development setup with several services each needing their own domain (an API, a frontend, an admin panel), a single wildcard-style local certificate covering *.localhost or a similar pattern, combined with local DNS entries for each service subdomain, avoids needing a separate certificate for each individual service.
A closing note on treating local HTTPS as a standard part of your development setup
Given how straightforward tools like mkcert have made this, treating local HTTPS as a standard, default part of any new project's setup, rather than an occasional special case, avoids the entire category of HTTPS-specific bugs that only surface once a project actually reaches production.
A final practical tip for team consistency
Documenting your team's chosen local HTTPS approach in your project's README or onboarding documentation ensures every new team member sets up a consistent, working local environment without needing to rediscover the correct process independently.