Tiny Little Office is kantoorpakket waar docs alleen in hun eigen URL bestaan

Een groep privacybewuste programmeurs heeft een Office-tool gemaakt waarbij ieder document alleen als een URL bestaat. Tiny Little Office zet de tekst, berekeningen of presentaties in documenten om in een Base64-URL. Daardoor hoeft een document niet centraal te worden opgeslagen, maar blijft het wel leesbaar voor iedereen met de link.

De tool heet Tiny Little Office en is een project van de makers van AI-tool Aboard. Zij hebben de broncode van de software op GitHub gezet onder een MIT-licentie. Daar staan ook mogelijkheden de tool zelf te hosten.

Tiny Little Office is een browsertool waarmee gebruikers tekstdocumenten, spreadsheets en presentaties kunnen maken. Er is ook een agendatool en zelfs een vakantieplanner in de software aanwezig. Als gebruikers een document aanmaken, wordt alles omgezet naar platte markdowntekst. Dat wordt vervolgens omgezet naar Base64URL, een aangepaste versie van Base64 voor gebruik in URL's.

Dat betekent dat het volledige document in zijn eigen URL staat. Om dat te illustreren, hebben de makers een introductiedocument geschreven en opgeslagen als een lange URL.

De makers zeggen dat de bestanden niet worden opgeslagen op een server en dat iedereen met de juiste URL een bestand kan openen. Wie documenten wil delen zonder dat anderen die kunnen lezen, kan ook een wachtwoord gebruiken om ze te versleutelen. Handig voor wie eens belangrijke, maar gevoelige informatie wil delen.

Tiny Little Office

Door Tijs Hofmans

Nieuwscoördinator

16-10-2026 • 18:49

14

Reacties (14)

Sorteer op:

Weergave:

o wow, en dat past? er zit toch een max aan je url lengte?
Als je hem post naar een server wel. Zolang het met js in de browser is volgens mij niet.
Jawel, ergens tussen de 30k en 60k chars afhankelijk van de browser. :P
Dat is een vaak gehoorde opmerking, de werkelijkheid is zeer afhankelijk van de omstandigheden:
  • RFC 9110: 8kb (recommendation);
  • Apache: configureerbaar (LimitRequestLine) tot het maximum van een 32-bit integer (ong. 2GiB);
  • IIS: in theorie configureerbaar (maxUrl, maxQueryString en UrlSegmentMaxLength) obv 32-bit uint (ong. 4GiB); in de praktijk gecapped op 16MiB door de Windows http stack.
UrlSegmentMaxLength is standaard 260 op Windows, waardoor de verwarring denk ik is ontstaan.
De makers zeggen dat de bestanden niet worden opgeslagen
Waar worden die URL's dan opgeslagen? In de aether of zo?
  • Overal waar jij het besluit op te slaan, bv. in een bladwijzer;
  • in je browsergeschiedenis en
  • als je het kopieert, dan ook in je klembord(geschiedenis).
De tekst zit in die URL, de editor leest dat uit. Er is geen serveropslag voor nodig, er is zelfs geen lokale opslag nodig, want het zit in de URL.

Het is vergelijkbaar met Google Translate, alleen weten we dat Google alles ook opslaat, ze maken het je alleen gemakkelijk om vertalingen te delen of via je browsergeschiedenis terug te vinden. Bovendien heeft Google Translate een karakterlimiet van 5000 tekens, dat is met deze dienst niet het geval, dus de limiet is heel hoog en gebaseerd op browserlimieten voor data URLs (heel groot).

[Reactie gewijzigd door Blizz op 16 oktober 2026 19:04]

De url staat nog steeds op de server, dus wat schiet je hier nu mee op.
Tja, de documentatie beweert dat het niet op de server wordt opgeslagen. Dus het zal aan eventuele logging(sduur) liggen, maar de suite zelf doet niet aan opslag. Bovendien kun je het zelf hosten.

[Reactie gewijzigd door Blizz op 16 oktober 2026 19:08]

Je bedoelt in de logfile van de http server?
Nee dat staat iets op de server, de url is de data waarmee het document wordt gegenereerd op het moment dat jij die url opent. Er is geen reden om de url op te slaan.
Je maakt gewoon een bestandje op je PC (onder Windows met de 'extensie' .URL) en daar schrijf je de URL in (in ASCII tekens). Bijvoorbeeld "Tiny Little Office is een kantoorpakket waar docs alleen in hun eigen URL bestaan.URL".
Gewoon encoded URL, die sla je op in een .txt file 😂
Niet bij hun in ieder geval. De URL bevat je volledige document, de lezer haalt de data direct daar uit.

In het geval van dit nieuwsartikel staan desbetreffende documenten dus in dit tweakers-artikel opgeslagen.
Dan moet een bedrijf haar backup strategie ook aanpassen. De desktop (waar veel mensen snelkoppelingen naar documenten plaatsen en nu dus de volwaardige documenten) en alle andere locaties waar men van alles neerzet. :-(

Om te kunnen reageren moet je ingelogd zijn