GitHub Pages provides free HTTPS for both the default github.io subdomain and connected custom domains, provisioned automatically once DNS is correctly configured.
Enabling it
Under your repository's Settings → Pages, once your custom domain is added and DNS verified, check "Enforce HTTPS." This checkbox is disabled/grayed out until GitHub has finished issuing a certificate for your domain, which can take anywhere from a few minutes to about 24 hours.
If it stays greyed out
This almost always means DNS isn't fully correct yet — double-check your domain's A records (for an apex domain) or CNAME record (for a subdomain) exactly match GitHub Pages' documented values.
Why the Enforce HTTPS checkbox stays greyed out longer than expected sometimes
GitHub needs to both verify your DNS is correctly pointed and complete Let's Encrypt certificate issuance before the checkbox becomes available — this combined process can occasionally take up to 24 hours even with correct DNS, longer than some other platforms covered in this category, so patience is warranted before assuming something is actually broken.
What DNS record types GitHub Pages expects for apex versus subdomain setups
An apex domain (yourdomain.com) requires specific A records pointing to GitHub's IP addresses, while a subdomain (www.yourdomain.com) uses a CNAME record pointing to your GitHub Pages URL instead — using the wrong record type for your specific domain structure is a common setup mistake worth double-checking against GitHub's current documentation.
Why removing and re-adding the custom domain sometimes resolves a stuck state
If a domain's HTTPS status appears permanently stuck despite correct DNS, removing the custom domain from repository settings and re-adding it can sometimes reset GitHub's verification and issuance process — a reasonable troubleshooting step after confirming DNS is genuinely correct and propagated.
What GitHub Pages' build process means for HTTPS-related Jekyll configuration
If your GitHub Pages site uses Jekyll, its _config.yml file's url setting should reference the https:// version of your domain, ensuring Jekyll's own URL generation for feeds, sitemaps, and templated links produces correctly protocoled output consistent with your enforced HTTPS setting.
How organization-owned repositories handle custom domain HTTPS differently from personal ones
The custom domain and HTTPS enforcement process works identically whether the repository belongs to a personal account or an organization — the main practical difference is simply who has the necessary repository permissions to access the Pages settings and make the relevant changes.
Why the CNAME file in your repository root matters for this entire process
GitHub Pages uses a CNAME file in your repository's root (or docs folder, depending on configuration) to know which custom domain to associate with the site — this file needs to exist and contain the correct domain for GitHub to properly validate and issue a certificate for it in the first place.
A closing note on GitHub Pages as a genuinely capable free hosting option
Between free hosting, free automatic HTTPS, and straightforward custom domain support, GitHub Pages remains a genuinely capable option for a static site, personal project, or documentation site, with HTTPS configuration requiring minimal ongoing attention once initially set up correctly.
What GitHub Pages' bandwidth and usage limits mean for this specific use case
GitHub Pages' usage limits (bandwidth and build minutes) apply independently of HTTPS configuration and don't affect certificate provisioning or the redirect behavior covered in this guide — a site approaching these limits would see them enforced separately from any HTTPS-related functionality.
How this guide differs for a project site versus a user or organization site
The custom domain and HTTPS enforcement steps apply identically whether you're configuring a project-specific repository site or a user/organization-level GitHub Pages site — the only practical difference is where the Pages settings live within GitHub's interface, not the underlying HTTPS configuration process.