​​This year we’ve shipped a lot of updates that make your published documentation better — from new ways to manage and organize your docs sites, to improved API docs and better performance.

But published docs are only part of GitBook — and we’ve also been working a powerful feature and some other nice improvements that make the GitBook editor better than ever, too.

Reusable content

With reusable content, you can create and reuse blocks of content across your documentation. When you edit the original content, those changes sync across all of its instances — making it easy to update published docs faster than ever.

There are plenty of uses cases. We’ve seen beta testers using synced blocks to build banners advertising a virtual event, adding alerts to tell their users that they’re looking at an older version of the docs, single line-paragraphs that describe common product features, beta feature disclaimers to include at the bottom of several pages, and many more.

The ability to have content syncing between pages is one of the most requested features in GitBook. By building it now, we aim to give content creators and technical writers more power over how they structure their content.

Our hope is that synced blocks help GitBook users scale their content, without compromising on the editing workflows or quality controls that make GitBook what it is today.

Getting started with reusable content

So how does it work?

Reusable content lives in a space, meaning it falls under the same editing and collaboration workflows you’re used to. You can edit reusable content just like any other content — using change requests or live edits.

To get started, select one or more blocks, then click the Options menu and choose Convert to reusable content. Once you’ve done this, you can add it to other pages from the Insert menu, by pressing / on an empty line or by clicking the + button. You can view, edit and manage all your reusable content in the space’s table of contents, by choosing the Reusable content tab at the top.

As we build more tools for managing content at scale, it’s really important to us that we don’t compromise on the values that bring users to GitBook today. So if you’ve built a review workflow around change requests, you’ll still be able to use that same workflow when you create and edit reusable content.

Right now, you can only add reusable content to the space in which is was created — but we’re working hard on adding the ability to sync reusable content across all spaces in your organization.

Reusable content and Git Sync

A lot of our customers rely on GitBook as the bridge between technical writers and the technical teams that they work with. And one of our goals as a company is to help close that gap — which is why Git Sync is so central to workflows in GitBook.

If you’re using Git Sync, it will export your reusable content to your Git repository as individual Markdown files. Whether you’re a GitBook editing expert or a Markdown wizard, you’ll be able to work with reusable content and start using it throughout your documentation.

Building correct support for Git Sync was one of the main factors behind our decision to have reusable content live at the space-level. By building clear ownership of each piece of reusable content, we can export them to a dedicated includes folder in the repository, without worrying about multiple spaces — and therefore multiple repositories — all claiming ownership over the same content.

Reusable content is available today as an alpha feature for Pro and Enterprise users, and we’re keen to hear your feedback. We’ll be rolling it out more widely very soon, so stay tuned to find out when you can try it for yourself.

Broken and internal link detection

A few months ago, we released broken link detection for internal links. Since then, we’ve been optimizing it to make it more useful than ever for avoiding publish docs with links that lead to a 404.

You can see if a space has broken or internal links from the icon in the space header. Click it to open the side panel, where you can see any links to pages that no longer exist, or links to unpublished pages in your GitBook organization. You can use this information to update the broken links and replace internal links with relative links to published pages.

Right now, this feature just shows links to other GitBook pages, but we plan to add more link types in future! Head to our docs to find out more.

Copying files and images across spaces

If you’re working on your product or API docs, it’s common to want to copy and paste files like images or your OpenAPI schema between different spaces. Until now, that wasn’t something GitBook supported.

The reason? It comes down to how files work in GitBook. Unlike some other editing tools, GitBook stores and versions files along with the content. That’s great if you ship a brand new UI for your product and want to update the screenshots in your docs to match — you can simply replace the old screenshot file with the new one. When you merge your change request, you’ll see the image updated everywhere and your space’s history will show the change correctly.

That’s the power of GitBook’s versioned content model — but it also means moving images and files between spaces is a bit more tricky than in a traditional editor.

But not any more.

Now, when you copy any block that includes a file — such as an image or an API block — and paste in a new space, the file will come along with you.

The file is copied into the target space, so you’ll still get all the change and asset management you’d expect from a GitBook space.

Images, API blocks, and other files all contribute to having rich documentation your users will love. We want the GitBook content model to make working with these assets as powerful as possible, and these changes help make that even more of a reality.

→ Explore the reusable content documentation

→ Read about the future of documentation

→ Get started with GitBook for free