GitHub Pages hosts static files from a repository. It can serve an exported form interface, but it does not turn that form into a private submission processor or protect secrets placed in front-end code.
Prepare the static files
Start with the exported index.html, form.css and form.js. Keep them together or update the HTML references to match your repository structure. Commit only public front-end files and documentation; never add credentials or private destination tokens.
Account for project-site paths
A user or organization site can publish at the domain root, while a project site commonly includes the repository name in its URL. Prefer relative asset references for a self-contained folder or configure the site base path consistently.
Configure the Pages source
In the repository settings, choose the branch and folder or the supported Actions workflow that produces the site. Wait for the deployment to finish, then open the exact Pages URL rather than assuming a successful commit means a successful website.
Test the real destination
GitHub Pages serves the browser interface only. A standard form still needs an external HTTPS endpoint you control, while email and messaging modes hand an editable draft to the visitor's application. Test the complete path on the published HTTPS page.
Frequently asked questions
Can GitHub Pages process form submissions?
GitHub Pages is static hosting. Use an external HTTPS endpoint or a visitor-controlled email or messaging handoff for the destination.
Can I put an API secret in form.js?
No. Repository contents and browser-delivered JavaScript are public to site visitors.
Why do assets work locally but fail after publishing?
Project sites may use a repository-name base path. Check the deployed URL and use paths that match that location.
Primary sources
Turn the guide into a working form
Start from a template, change the fields and take the code with you.
Open the free builder