Hosting your resume or portfolio on GitHub Pages
How GitHub Pages works, what it is actually good for, and where it stops being the right tool once you need a resume that recruiters can search and parse.
关于此页面
网站界面已按你选择的语言显示。本页的长篇正文以英文撰写，目前尚未翻译。
GitHub Pages is a free static hosting service built directly into GitHub. Push HTML, CSS, and JavaScript to a repository, turn Pages on in the repository settings, and GitHub serves it at your-username.github.io or your-username.github.io/repo-name, with no server to configure and no hosting bill.
The setup, briefly
Create a repository named exactly your-username.github.io for a top-level personal site, or use any repository name for a project-specific page served at a subpath. In the repository’s Settings, under Pages, choose the branch to publish from (usually main), and GitHub builds and deploys the site automatically on every push. Changes typically go live within a minute or two.
It also supports Jekyll natively, GitHub’s own static site generator, which means a full personal site can be built from Markdown files without touching a build pipeline yourself, or you can push a plain index.html and skip Jekyll entirely.
Where it genuinely works well
A developer portfolio site: project write-ups, an about page, links to repositories, maybe a blog. A single-page personal site that just needs to exist somewhere permanent and free. A project’s documentation or demo page, hosted right alongside its source code.
For all of these, the free hosting, integration with a repository you likely already have, and near-zero setup make GitHub Pages a genuinely good default.
Where it stops being the right tool: an actual resume
Hosting a resume as a webpage on GitHub Pages is a reasonable idea, and worth doing as a portfolio piece. But when an employer’s application system specifically asks for a resume upload, a link to a webpage usually is not what it wants, and for two concrete reasons.
Applicant tracking systems parse an uploaded document, typically a PDF, into structured fields it can search and filter on later. A link to a hosted webpage generally does not get parsed the same way, and in a lot of ATS configurations, a URL where a file upload is expected simply gets rejected or ignored. Recruiters searching a database of candidates by keyword are searching indexed document fields, not crawling links out to external pages.
The practical result: a GitHub Pages site is an excellent complement to a resume, worth linking from the contact section, but it is not usually a substitute for the PDF itself in most application flows.
The version that works both ways
The strongest setup uses both: a GitHub Pages portfolio that goes deep on projects and writing, linked from a resume that is still a proper, parseable PDF document for the applications that specifically require one.
resumefromgit.com generates that PDF directly from a public GitHub profile, pulling in the same repositories you might feature on a Pages site, formatted as a single-column, ATS-safe resume rather than a webpage. Used together, the visual site is where someone goes to look closer; the PDF is what actually gets uploaded and parsed.