GPRM: a generator for the README on your GitHub profile

What the tool produces, and where it goes

GPRM is the GitHub Profile ReadMe Maker, a web application that generates the README file shown on a GitHub profile, and the output is a markdown document that you place in a repository GitHub renders on your profile page.

The usage section is the shortest description of the whole project: you can copy the generated ReadMe and paste it into your GitHub ReadMe file directly, or you can download the markdown file, which is called `README.md`, and just add it to your GitHub repo.

Those are the two delivery mechanisms and they have different consequences. Copy and paste means the file exists only on your profile and is edited in the browser. Downloading a file means it lives in a repository, so it is versioned, diffable and reviewable, and it can be regenerated later.

The application itself is a Next.js app with the live site at `gprm.itsvg.in`, and the project describes itself as a profile generator with lots of features and tools included, all for free.

The primary language is JavaScript, the licence is GPL-3.0, the default branch is `main`, and the last push was on 2026-04-12. There are no GitHub releases, and the site is the deployed artefact, so the repository is a source tree for a service rather than a distributed package.

The feature list is a list of other people's images

The features are worth reading as a list of embeds, because that is what most of them are.

The statistics section is the core. With tools such as ReadMe Stats, Most Used Languages and Streak Stats, the profile shows a summary of the account's public activity, which are cards rendered by separate services. The visitors counter works the same way, giving an idea of how many people have looked at the profile, and the GitHub trophies feature adds virtual medals to the page, which are the third-party trophy images. The tech stack section is a list of more than 300 technologies to choose from, shown as icons. The social links and the donation links are the parts that are genuinely the user's own content, and the fun components, which add random memes and quotes, are the part that is decoration.

So the generator is a user interface for assembling a page, and a large part of what it assembles is a set of image URLs pointing at other people's servers, embedded in markdown that GitHub renders. That is a perfectly reasonable thing to want, and it is also a set of third-party dependencies with all the properties that implies. A stats card that changes shape, a service that goes away, a request from every profile view to somebody else's infrastructure.

The claimed speed of creation is that it takes less than one minute on average to create a profile ReadMe using GPRM, and that is the whole value proposition in one sentence: the parts that are tedious to assemble by hand are exactly the parts that are already written as embeds, so what remains for the user is choosing which ones to switch on.

Next 12, React 17, MobX and a chat widget

The package manifest is short and it dates the project, which is useful to know before reading the rest of the repository.

  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "start": "next start",
    "lint": "next lint"
  },

The application stack is Next.js 12.1.0 with React 17.0.2 and React DOM 17.0.2, styled with Tailwind CSS 3.0.15 and PostCSS with Autoprefixer, and linted with ESLint 8.7.0 and the Next configuration. The state management is MobX with mobx-react, which is a reasonable fit for a form with a lot of independent toggles, since each of the profile's sections is a switch.

The rest of the dependencies are the individual pieces of the feature list. `axios` does the HTTP, `markdown-it` handles the markdown output, `@heroicons/react` provides the icons, `react-text-loop` is the component that cycles the quotes, `firebase` is the backend, and `crisp-sdk-web` is the support chat widget embedded in the site.

The repository layout is the standard Next.js one with a few additions. There is `pages/` for the routes, `components/` for the interface, `config/` for the option definitions, `data/` for the content the generator uses, `styles/` for the global styles, `utils/` for the helpers, and `public/` for the static assets.

The `config/` and `data/` directories are the parts that describe the product, because the tech stack options, the social link options and the quote and meme content are all data rather than code, and a new theme for a new framework is a data change.

Running it locally, and the pages router it was written for

The development instructions in the README are the Next.js ones, and they are the ones a contributor needs.

npm run dev
# or
yarn dev

The application is then on `http://localhost:3000`. The page auto-updates as you edit `pages/index.js`, and the API routes are accessible at `http://localhost:3000/api/hello`, edited in `pages/api/hello.js`, with the `pages/api` directory mapped to `/api/*` and its files treated as API routes rather than React pages.

That is the pages router, and it is worth pausing on, because Next.js has since moved its default to the app router. The project is on Next 12 with React 17 and the pages directory, and the code reflects that era: a `pages/` directory rather than an `app/` one, a `next.config.js` rather than the current configuration file, and a Tailwind setup of the 3.0 vintage. The `next build`, `next start` and `next lint` scripts follow the same convention.

For a contributor, the practical effect is that the local environment has to match, and a machine with a current Node and a current Next in mind is the wrong starting point. The repository also has an `.eslintrc.json` at the root, a `CODE_OF_CONDUCT.md` and a `CONTRIBUTING.md`.

For a user, none of this matters, because the deployed site is what anybody visits, and the site's own performance is reported with a PageSpeed Insights badge in the README, along with a link to the deployment on Vercel.

Two licences, two meanings

The licence of this repository is worth a paragraph, because there are two of them and they mean different things.

The repository is GPL-3.0, which is the licence for the source of the generator. The generated output is a markdown file with image and HTML fragments from other services, and the licences of those fragments belong to the services that render them.

That distinction is not academic for this particular project. A profile README that embeds a stats card is a page that displays somebody else's rendering of your data, and the terms under which that rendering is provided are the service's, not the generator's. The GPL covers the tool that assembles the file; it cannot cover what the file points at.

The consequence for a user is mild, since the output is a personal profile page and nobody is distributing it as a product. The consequence for a reader who wants to fork the generator and offer it as a service is not mild, and the GPL covers that case, because anyone who distributes a modified copy has to pass on the same freedoms.

So the honest summary is: the code is free software under a copyleft licence, the output is a composition of other people's work, and the two facts do not conflict.

Where GPRM is the wrong tool

The limits come from the same place as the features, which is that most of the output is somebody else's rendering.

The first is availability and ownership. A profile built from a stats card, a language chart, a streak counter, a visitors counter and a trophy wall is five or six services that have to be up, that have to keep the same URL shape, and that can change what they return without asking. Some of them are community projects. A profile that looked good last year can be half broken this year, and the fix is to change a URL in a markdown file by hand.

The second is that the result is not really a README in the sense people expect. A README is documentation, and a document you wrote. A profile README built by this tool is a display, and it is worth asking whether the person whose profile it is wants a display. The README in this repository, for instance, is a document about the project, and nobody would describe it as a profile page.

The third is the scale of what is being generated. The features are shallow individually and add up quickly, and the result is a page that says a lot without saying much. A hand-written profile README of fifteen lines, with a link to the projects and a line about what the person is doing, is often a better profile than a generated one, and it is a better read.

The alternative, for somebody who wants the embeds but not the generator, is to copy the image URLs for the few cards worth having and write the markdown around them, which takes a fraction of the minute the generator claims to save and gives a page with fewer dependencies. The difference in approach is that the generator optimises for the visual result and the time to reach it, and the alternative optimises for a page that is yours and stays yours, and a developer who cares about the second one will spend the minute.

Editorial conclusion

GPRM fits a developer who wants a profile page that looks like something, who is not going to hand-write the HTML for a streak counter and a trophy wall, and who will accept that the result is a list of embeds from other services. It is the wrong tool for somebody who wants a profile README that is theirs, because most of what the generator produces is a third-party image rendered inside a markdown file, which means the content and the availability of a large part of the profile belongs to somebody else's server. Before using it, look at the generated markdown and count the third-party requests, and consider writing the handful of lines by hand, because the maintenance cost of a page made of embeds is paid every time one of them moves.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. README
5. VishwaGauravIn/github-profile-readme-maker on GitHub