Distl

For the next wall of text.

Less text.More clarity.

Distl summarizes selected article text, supported AI replies and open emails in Chrome. Read the key points beside the original, without leaving the page.

For the things you read every day.

Long text.
Clear takeaway.

The important part, brought forward. See it in emails, AI replies, articles, and more.

Illustrative AI conversation · Full example

Should our small team launch with microservices?

Full example · scroll to read

You: "We are three engineers launching our first product. Should we use microservices now so we will not have to rebuild everything when we grow?"

AI assistant:

Microservices can be a good choice when different parts of a system need to scale or deploy independently. However, those advantages come with work that is easy to underestimate at the start. Each service needs deployment automation, monitoring, authentication boundaries, and a plan for handling failed requests between services. A small change can also require coordination across several repositories.

For a three-person team still finding its first customers, I would start with a modular monolith. That means one application and one deployment, but clear boundaries between accounts, billing, and the core product. Keep the modules from reaching into each other’s internal data so those boundaries remain useful as the codebase grows.

You can make this easier to operate with a managed database, automated backups, error reporting, and a straightforward release process. Those choices address problems you are likely to encounter soon. Building a distributed system for traffic you have not seen yet can take time away from learning whether people want the product.

Revisit the architecture when one module needs independent scaling, teams repeatedly block each other’s releases, or ownership has become difficult to manage. At that point, you can extract the specific service that needs independence. You do not need to split everything at once just because one part has outgrown the original structure.

Summarize

Start with a modular monolith.

Keep accounts, billing, and core logic separate inside one deployment. Split services when scaling needs, release conflicts, or team ownership justify the operational cost.

242 words → 29 words~61 sec → ~8 sec · ~53 sec savedEstimated at 240 words/min

The recommendation, the reason, and when to reconsider.
Illustrative email · Full example

Launch review: final materials and schedule

Full example · scroll to read

From: Jordan Lee <jordan@example.com>
To: Maya Patel <maya@example.com>
Subject: Launch review: final materials and schedule

Hi Maya,

Thanks again for walking us through the launch proposal yesterday. The team liked the revised positioning, especially the clearer explanation of who the product is for. We have moved the review from Tuesday to Friday so finance can check the updated numbers before we choose a direction.

Design is working on the new screenshots, and Leo will put them in the shared folder when they are ready. You do not need to make those changes yourself. We will use the existing mockups for the internal briefing if the final images are not ready in time.

Could you send the revised budget and confirm which of the two headline options you recommend? Please send both by Thursday at 3 pm so we can include them in the review pack. If any budget assumptions have changed since our discussion, flag those in your reply; there is no need to rewrite the whole proposal.

Once your materials arrive, I will assemble the presentation and circulate it to everyone attending. As Priya put it in yesterday’s call, "The review should help us choose a direction, not reopen every design decision." A short explanation of your headline choice will help us keep that conversation focused.

Thanks,
Jordan

Summarize

Budget + headline by Thursday, 3 pm.

Send your recommendation and flag changed budget assumptions. The review moved to Friday. Design owns the screenshots; Jordan will assemble the presentation.

219 words → 29 words~55 sec → ~8 sec · ~47 sec savedEstimated at 240 words/min

Your tasks and deadline stay clear, without taking on someone else’s work.
Illustrative article excerpt · Full example

Why more meetings do not always mean better coordination

Full example · scroll to read

When a team struggles to coordinate, the most visible response is often to add another meeting. A weekly status call becomes two calls, and then a daily check-in joins the calendar. Everyone spends more time talking about the work, yet the same questions still appear in messages later that afternoon.

The underlying problem may be that decisions are not recorded where people can find them. A meeting shares information with whoever attends, but it does not automatically create a useful record for everyone else. People returning from leave or joining a project later must ask someone to reconstruct what happened and why.

A shared decision log solves a different problem. It records the decision, the reason, the owner, and the next step. Routine progress updates can sit beside that record and be read when needed. This does not mean all conversations should disappear: ambiguous choices, disagreements, and urgent blockers still benefit from people talking directly.

Start with a small experiment rather than a company-wide rule. Replace one recurring status meeting with a written update, make the decision log easy to find, and review the results after two weeks. Ask whether people found answers more easily and whether blockers took longer to resolve. Restore a focused discussion if needed. The goal is dependable coordination, not simply a calendar with fewer entries.

Summarize

Write decisions down. Keep useful discussions.

Record the decision, reason, owner, and next step. Trial replacing one status meeting with written updates for two weeks; keep live conversations for disagreements and urgent blockers.

220 words → 33 words~55 sec → ~9 sec · ~46 sec savedEstimated at 240 words/min

The central argument and a practical way to test it.
Illustrative study abstract · Full example

A pilot study of retrieval practice in adult learning

Full example · scroll to read

This pilot examined whether answering questions from memory improved retention more than rereading the same material. Sixty adult learners took part during a four-week online course. One group completed brief retrieval exercises after each lesson, while the other spent an equivalent amount of time reviewing the lesson notes.

Both groups completed an assessment immediately after the course and a second assessment two weeks later. The retrieval group performed better on the delayed assessment. The difference between groups was smaller on the immediate assessment, suggesting that the benefit was more apparent after some time had passed.

Participants also reported that answering from memory felt more difficult than rereading. This is relevant when interpreting learner preferences: an activity that feels easier during a study session may not produce the strongest later recall. The pilot did not establish whether perceived difficulty affected completion rates over a longer course.

Several limitations restrict the conclusions. The sample was small and drawn from a single course, and outcomes beyond two weeks were not measured. Prior knowledge may also have influenced performance. The findings support further investigation of retrieval practice, but they do not establish the size or reliability of an effect across other subjects, institutions, or learning environments. A larger study with longer follow-up would be needed before making broader recommendations.

Summarize

Recall practice improved two-week retention.

Answering from memory beat rereading in this 60-person pilot, despite feeling harder. Treat the finding as preliminary: one course, a small sample, and no longer follow-up.

215 words → 31 words~54 sec → ~8 sec · ~46 sec savedEstimated at 240 words/min

The result stays attached to the limits of the evidence.
Illustrative membership policy · Full example

Annual membership cancellation and renewal policy

Full example · scroll to read

Annual memberships renew automatically on the anniversary of the original purchase. We send a reminder to the email address associated with the membership fourteen days before renewal. Please keep that address current so you receive billing notices and any information about changes to your membership.

You can turn off automatic renewal at any time in your account’s billing settings. Turning it off stops the next renewal payment; it does not immediately cancel the access you have already paid for. Your membership remains available until the end of the current paid period.

Refund requests for an initial annual purchase must be received within fourteen days of purchase and are eligible only if no member-only resources have been downloaded. Renewal payments are not included in this initial-purchase refund window. If you believe a renewal was processed in error, contact support with your receipt so the payment can be investigated.

Changes to the annual price apply at the next renewal, not during the period already paid for. We will give at least thirty days’ notice before a new price applies, allowing you to disable renewal beforehand. These are the standard membership terms. If your organisation has a separate written agreement, consult that agreement for any conditions that differ from the policy described here.

Summarize

Auto-renewal. A conditional refund window.

Turn renewal off in billing and keep paid access. Initial refunds: within 14 days, with no downloads. Renewals are excluded; price changes require 30 days’ notice.

210 words → 31 words~53 sec → ~8 sec · ~45 sec savedEstimated at 240 words/min

Cancellation, refunds, and exceptions in one view. These are example terms, not Distl’s billing policy.
Illustrative migration guide · Full example

Moving a project to a new hosting environment

Full example · scroll to read

Before moving the application, make a fresh database backup and record the environment variables the current deployment uses. Store secrets in an approved password manager or secret store, not in a public repository or issue tracker. Confirm who can restore the backup and where the restoration instructions are kept.

Create the new hosting environment with the required runtime version. Add configuration through the provider’s secret settings, then deploy a preview using the application’s normal build process. Test login, a read, a write, and background jobs before switching traffic. A successful home-page load alone does not verify those flows.

Prepare the DNS change ahead of the cutover by lowering the record’s time to live. Choose a quiet period and tell the people responsible for support when the move will happen. If the database migration needs a final export, pause writes before taking that copy so new records are not lost between the two environments.

Switch DNS to the new host and monitor errors, response times, and scheduled jobs. Check the critical flows again once real traffic reaches the new environment. Keep the old environment available until the new one is stable and you have confirmed that no traffic or scheduled work still depends on it. Use the old deployment as the rollback option if a critical check fails.

Summarize

Back up → preview → test → switch.

Secure the configuration and test login, reads, writes, and jobs. Prepare DNS; pause writes for a final export. Monitor after cutover and keep the old host ready for rollback.

217 words → 37 words~55 sec → ~10 sec · ~45 sec savedEstimated at 240 words/min

The sequence and the precautions stay together.
1 / 6

Illustrative examples, not private emails, published research, or live-generated results.

A few minutes of reading.
A few lines to get the point.

Use the short version to find what matters. Go back to the original when you need the detail.

A 1,200-word article

5 minto read the original

A 60-word summary

15 secto read the short version

Fits into your reading.
Stays out of your way.

No copying into another app. You choose the text, then ask for the short version.

How your text is handled ↗
Do I have to copy and paste?

No. Click Summarize beside an AI reply, Summarize on an open email, or select text on a webpage. The summary appears beside what you are reading.

What gets sent for a summary?

Only the text for that summary: your selection, a chat reply and the question before it, or an open email without its quoted thread. Summaries are processed in the cloud. No page URLs or browsing history are sent. History is off by default.

Where does Distl work?

Normal webpages, ChatGPT, Gemini, Claude, Gmail, Outlook, and Yahoo Mail. It does not run on Chrome settings, the Web Store, the built-in PDF viewer, or canvas editors such as Google Docs.

All questions ↗

Try it on your next long read.

50 free credits every month. No card required.

See plans and credit details ↗
Get Distl for Chrome

Make your writing shorter

Try our free sentence and paragraph shortener to edit wordy text, compare word counts and copy a shorter version.