goodshare.js: share buttons in one kilobyte and no tracking

Share buttons without a dependency and without a tracking script

goodshare.js is a modern JavaScript solution for sharing a link from your website to social networks and mobile messengers, and the section asking why it exists lists the reasons in a single paragraph.

There is a simple install, extensive documentation, developer support, and SEO friendly behaviour. There is a small bundle size, given as 1.04 KB with all dependencies, minified and gzipped. There are many options for customization of appearance, clean code, and no scripts tracking user activity on the page. And there is high speed.

That last pair of claims is what separates this from most share widgets. A conventional share bar is a bundle of several third party scripts loaded from a content delivery network, each of which observes the page and often the visitor, and each of which you do not control. This one is a single file that does not make network requests and does not report anything, so the page stays private and fast.

The bundle number is the headline and it is enforced rather than asserted. The badge gives 1.06 KB, and the size limit report in the readme records a time limit of 80 ms, a size of 1.06 kB gzipped, a loading time of 21 ms on slow 3G, a running time of 54 ms on Snapdragon 410 and a total time of 75 ms.

So the claim is not just about weight. It is about time: 21 ms to load on a slow 3G connection, 54 ms of running time on a Snapdragon 410, and 75 ms in total against an 80 ms limit. A Snapdragon 410 is a deliberately modest phone, which is the right reference device for this kind of library.

The size limit is measured rather than estimated, and the report is generated by a script in the package manifest, which runs the build and then the size-limit tool. The limit configuration lives in a .size-limit.js file at the repository root, so the budget is in the repository and a change that breaks it fails the check. The scripts that produce all of this are:

  "scripts": {
    "update": "npm outdated && npx npm-check-updates -u && npm install",
    "build": "rollup --config rollup.config.js --compact --bundleConfigAsCjs",
    "watch": "rollup --config rollup.config.js --watch --compact --bundleConfigAsCjs",
    "size": "npm run build && size-limit"

The build script runs Rollup with the compact flag and the bundleConfigAsCjs flag, the watch script is the same with the watch flag, and the size script runs the build and then the size-limit check. The update script runs the outdated check, then updates the dependencies with the update-checker tool, then installs.

The project is MIT licensed, the primary language is JavaScript, and the homepage is goodshare.js.org. The last push was on 2026-04-10.

One attribute on any tag, and the metadata it reads

The API is small enough to describe in a sentence. It works with any HTML tags, an anchor, a div, a button or other, and you choose any and add the required data-social attribute. The four examples in the readme are a button for Twitter, a link for Facebook, a div for LinkedIn and an icon element for Tumblr.

Every one of those four examples is the same mechanism with a different tag, and the fourth one is the interesting case, since the icon element carries a class from an icon font and the data-social attribute. That makes it a share button with no text in it at all, so the visual design is entirely the site's own and the library contributes only the behaviour.

That is why the library claims to work with any tag. It is not building buttons, it is attaching a click handler that constructs a share URL, and a tag is just something to click.

The other half is where the content comes from, and by default the library searches the page tags for the title, the description and the image, for some social networks. The tags it looks at are the document title, the description meta tag and the apple-touch-icon link element.

That is the standard set of metadata a site already has, which is what makes the zero-configuration claim work.

The link element is the one worth noting, because apple-touch-icon is what a mobile messenger or a messenger preview uses as the preview image, and many sites have it while not thinking about it as share metadata at all.

There is a full list of supported social providers and mobile messengers on the documentation site, and the two are separated in the links, which reflects the distinction the library draws between a network with a share URL and an application you hand content to.

For the framework-specific cases, the readme lists a Vue.js component, maintained by the same author, as a framework component. That is the only one listed, and the way it is presented, as a separate repository, tells you the core library is deliberately framework agnostic and the integrations live outside it.

A single file on a CDN, and a build that produces exactly that file

Installation offers the three package managers, npm, pnpm and yarn, and one CDN route, and the CDN route is the one that matches the library's philosophy best.

And from jsDelivr the script tag is the goodshare.min.js file at a major version:

That is a single script tag pointing at a minified file on a content delivery network, with a major version in the URL so the file can be updated without changing your markup. There is no build step, no dependency resolution and no lock file for the visitor's browser to fetch, which is the whole reason the bundle is small enough that the CDN route is viable.

The build that produces that file is Rollup with Babel and the Closure Compiler plugin, and the package manifest records the scripts it runs. The source is modern JavaScript, Babel transpiles it for older browsers, and the Closure Compiler pass minifies it. The Closure plugin is the interesting one, because Closure does more than strip whitespace: it does dead code elimination and it can rewrite the code, which is how a library gets to a thousand bytes without giving up readability of the source.

The main field in the manifest points at the built file, goodshare.min.js, and that file is committed to the repository root rather than built at install time. So a consumer who installs from npm gets the same artefact the CDN serves, byte for byte.

The scripts are three. The build script runs Rollup with the compact flag and the bundleConfigAsCjs flag, the watch script is the same with the watch flag, and the size script runs the build and then the size-limit check. The update script runs the outdated check, then updates the dependencies with the update-checker tool, then installs.

The rollup configuration is at the repository root as a .js file rather than a JSON one, and the same bundleConfigAsCjs flag appears in the script, which is the required opt-in for a CommonJS configuration file in current Rollup versions. There is also a .babelrc and a .prettierignore, and the code style is prettier, which is called out with a badge in the readme.

Who maintains it, and how the project asks for support

The developers section names the idea and active development by Vic Shóstak, also known as Koddr, and one collaborator, Ilya Reshetnikov, also known as devxom. That is a two person project with a very large install base, and the readme does not pretend otherwise.

The project assistance section is more unusual than the credits. It asks for three things, in order. Add a GitHub star to the project. Tweet about the project on Twitter, with the tweet text and the share link prepared for you. And join DigitalOcean at the referral link, with the note that your profit is $100 and the project gets $25.

The referral link is a specific kind of sponsorship arrangement, and its presence in a readme is worth noting as a cultural marker. The author runs the project for free and asks for stars, attention and a hosting referral rather than money, and the DigitalOcean badge at the bottom of the readme is the receipt for that.

The contributing side is handled through OpenCollective, with the contributors graphic pointing at an OpenCollective URL for the project, and a separate sentence stating that the project exists thanks to all the people who contribute.

There is a stargazers over time chart linked with the starchart service, which is a small detail that tells you the project has been running long enough for a star count to be a graph rather than a number.

The framework components section is worth a second look, because it is where the split between the core and the ecosystem is made visible. There is one entry, a Vue.js component at a separate repository under the same author, and the library core has no framework code in it at all. A Vue wrapper has to deal with the framework's rendering model and the framework's lifecycle, which is why it lives outside the library rather than being bolted on.

So the shape of the project is a small framework-agnostic core, a separate wrapper for one popular framework, documentation published from the repository, and a sponsorship model based on attention rather than money. It is a common shape for a library that has become infrastructure without becoming a business.

The changelog is linked from the top of the readme next to the documentation link, and given the release history that link matters more than usual.

The docs are a separate site built from the same repository

The documentation lives at goodshare.js.org and the readme links a change log, and the way the site is built is worth a look because it says something about how the project is maintained.

There is a mkdocs.yml at the repository root and a docs/ directory, so the documentation is written in Markdown and built with MkDocs. And there is a Makefile whose only target is gh-pages, which does the whole publication in one step.

The target removes the site directory, builds the documentation with mkdocs, checks out the gh-pages branch, copies the built site into the branch root, removes the build directory, and commits the result with the message Update docs. The final echo line says the docs were created and are waiting to deploy to the gh-pages branch. The whole target is:

gh-pages:
	rm -rf ./site \
	&& mkdocs build \
	&& git checkout gh-pages \
	&& cp -R ./site/* ./ \
	&& rm -rf ./site \
	&& git add . \
	&& git commit -m "Update docs"

So the documentation is published from the repository itself, to a branch, on a schedule that follows the commits rather than being hosted on a separate service. That means the docs version and the code version cannot drift, which for a library whose documentation is its primary interface is the right arrangement.

The published file is then served from goodshare.js.org, so a reader looking for the supported social providers or the messenger list is reading documentation built from the same commit as the code.

The examples directory holds a single file, 01_full_buttons.html, which is the complete set of buttons in one page. That is a small but deliberate choice: rather than a set of partial snippets you have to assemble, there is one page that shows every button, so you can copy the pattern for the ones you want from a page that already works.

The top level also carries a .editorconfig, a .gitignore, a CHANGELOG.md and a .github/ directory. And the goodshare.min.js file at the root, next to the src/ directory, which is the committed build output that the manifest points at and the CDN serves.

The release history has a telling pattern. Version 6.2.0 in July 2021 was a dependencies release, version 6.2.1 in August 2021 was a security release, and version 6.3.0 in July 2023 was also a security release. So of the three most recent tagged versions, two exist because of a security problem, which is a good reminder that any script you embed on somebody else's site is an attack surface you have to keep patching.

Editorial conclusion

goodshare.js suits a site that wants share buttons without pulling in third party scripts that observe the visitor, since it is one file with no network requests and a size budget that is checked on every build. It does not suit you if you want the buttons to look a particular way out of the box, because the library supplies behaviour and the visuals are entirely yours, and it does not suit you if you need a provider it does not cover. Before you depend on it, read the change log rather than the readme, because two of the three most recent tagged releases were security releases, and a library embedded on other people's pages has to be patched like any other dependency.

Frequently asked questions

Official sources

1. koddr/goodshare.js on GitHub
2. License: MIT
3. Project website
4. README
5. Releases