I want to keep a digital journal on my computer. I keep a physical journal in notebooks and on pieces of sheets, but I now want to back up my journal on the computer and if needed maintain the journal on the computer.

I know of many different journaling apps. *I have tried Evernote and OneNote (my favourite of the two). But being an aspiring programmer, I have a great respect for text files. I know that text files are practically universally readable. If Evernote or OneNote is to become obsolete, I may never be able to recover my journal entries, because they are locked into the proprietory file formats in which Evernote and OneNote formats its data. I don't want to have my data locked into these file formats.

I want to keep my entries in plain-text files, marking up my file using restructured text markup.

My question is, how should I keep my files for the best organization and for later compilation? Should I keep my journal entries in one large file? Or should I keep my journal entries in separate files?


journal.txt <-- contains all entries





What do you think is the best way to organize journal entries in plain-text files?

(Keep in mind that I may later want to compile the entries into a book, using pandoc. Balance between the conveniences for now and later).

* -- If I had a Mac I would have settled for DayOne on any day, and would have bought it for any price; it's beautiful.

  • You said your concern about other formats is losing access to your data, and then you talk about text files. Are you only interested in plain-text options, or is plain text with markup (e.g. HTML, XML) a useful option? Commented Oct 8, 2013 at 21:45
  • I'm only interested in plain-text options, if I understand you correctly.
    – user6025
    Commented Oct 8, 2013 at 21:59
  • 1
    Have you tried BBEdit? barebones.com/products/bbedit Commented Oct 9, 2013 at 0:02
  • 2
    Scriver and/or Scapple from Literature and Latte literatureandlatte.com/index.php available for Windows & Mac. You can also export to text files if you need to move onto another solution. They offer a trial so you could test how the text export (compiler) formats too. Commented Oct 9, 2013 at 7:23
  • 2
    I was going to suggest Scrivener, but the OP explicitly didn't want something which was not plain-text. Scrivener does export as plain text and Word. Commented Oct 9, 2013 at 10:32

10 Answers 10


Recommend you check out TiddlyWiki, which is a single-page HTML file you can keep on your computer (or thumb drive, etc, or even check into version control).

The app creates small entries in the single-page file called Tiddlers, which you can later export to plain text for inclusion in a book, etc.

TW offers all of the indexing, search and add-on functionality you want while requiring only a browser. Everything is done in-browser by clicking on links, and there's a journal feature which creates a new entry with the date title on a single click.

It's been really useful for me to keep journals, knowledge bases, copybooks, etc. Check it out.

  • Tiddlywiki is cool. Never heard of it before. Thanks. Doesn't meet OPs requirements, but might be a great solution anyway.
    – Joe
    Commented Oct 16, 2013 at 5:01
  • I do like TiddlyWiki and I did play with it a long time ago as a personal note taking tool, but the non-linearity eventually seemed a little bit distracting to me. Another tool I used for a while was CintaNotes but left that after a couple of years since it doesn't play very nicely with my Linux system. Otherwise, it's fast, convenient, and very free of distraction. Commented Oct 16, 2013 at 16:28
  • I have just started using Zim (a desktop wiki that is backed by plain-text file-system-based storage) for purposed including keeping a journal. It uses it's own markup though.
    – user8014
    Commented Feb 20, 2014 at 13:40
  • It used to be a lot more functional, but the browser security updates (which are a good thing) have seriously impacted the grab-n-go usability. I don't use it as much any more in favor of OneNote but it's still trucking at the original site.
    – lonstar
    Commented Aug 17, 2015 at 22:14

I like to use this naming convention:

yearmonthday - optional_filename_or_description.txt

for example:

131012 - The day I did such-and-such.txt

This number format means that if you sort the files alphabetically they will always be in sequential order.

You could add dots if it makes it easier to read: 13.10.12 - etc.txt

I like to use Dropbox (http://dropbox.com/) to back up my files online because it happens without you having to do anything. When I want to protect private writings and information I use TrueCrypt (http://www.truecrypt.org/‎) to encrypt the files. This is a good idea when using any digital or online backup, as you never know when you might get hacked or have your computer stolen.

I also use a text editor that allows me to browse an entire folder of files in a sidebar, so I can easily jump around and browse different files. This gives me the best overview of all my work in progress. I use Sublime Text, (http://www.sublimetext.com/‎) but this feature can probably be found in other software that is more specifically for writers.


One file per year, fixed entry header format so that you don't have to guess, was that 4.Jul or July the 4th or 4.07 or 07.04 - pick any format you want but stick to it.

Why one massive file instead of many smaller ones? That way finding given entry is trivial using find tool. Appending at the end is less hassle than creating new files. But above all, searching is much easier. I mean: you have a keyword that repeats roughly 40 times across all your entries. You know the entry you look for contains it. If you use multiple files, you'll have to click every single file found that contains that word, read, close, open another, read, close... 40 times. With single file it's as simple as "find next" or F3. Also, with more advanced tools you can do more advanced searches, say, you remember 2 days in sequence, in one you wrote about a camera, in another you mentioned visit to your mother. There are hundreds of entries mentioning your mother and at least 40 about cameras. grep for camera including 40 context lines around each match, then find 'mother' within the found context. With one full line with specific sentence containing 'mother' you should be able to pinpoint the entry easily. You can still easily narrow down to "roughly end of spring" by scrolling to some halfway the length.

Oh, and plain reading, entry by entry, will be much smoother too.

  • Nicely explained. I agree, using search tools in one file is way easier than having to go through each file one by one. Thanks!
    – user6025
    Commented Oct 9, 2013 at 4:38
  • Using less to view files, it makes little difference for searching whether it's one file or many. Just press Esc before the / or ? that starts the search; thereafter press n to get to next or previous instance of search pattern in the set of files that less is viewing. Commented Oct 9, 2013 at 21:30

I've used quite a few note-taking tools over the years, and eventually stuck with Zim Wiki for a few reasons:

  • The underlying format is a set of plain text files automatically organized into folders when you create pages and sub-pages.
  • The plain text files can be rendered with just the right amount of formatting (headings, bold, italics, code blocks, checklists, bullet lists).
  • The available plugins are awesome and can be used to embed LaTeX equations, plots from the R programming language, and more.
  • It's cross-platform, so I can store my notebook files in Dropbox and access the same files whether on my Windows workstation in the office (bleah) or my awesome Ubuntu laptop at home (whoo!).
  • Autosave is awesome, and even more awesome when combined with a cloud syncing service like Dropbox.
  • Multiple notebook support--very nice when working on multiple projects.
  • If your notes for a particular day are long, you can use headings within the note, and a "table of contents" pane can be displayed in your window to easily navigate your entry.
  • At the end of the day you can export entire notebooks as markdown files, which means Zim + Pandoc = Love.

For your specific purpose, Zim Wiki also has an (inbuilt) "journal" plugin. You can see some of the settings here, one of which is to generate a new file for each day, week, month, or year. Based on your choice, Zim Wiki will store your files in different ways. For example, if you were going with a daily journal, it would create, say, a folder named "2013", under which it would create another folder "08" for "August", and a plain text file named "13.txt" for the thirteenth.


I have experimented with this over the years and have found that a single plaintext markdown file under Git source control is the way to go for a chronological journal. If you store it on GitHub you can even edit the file in a browser if necessary. I tried chronological order and reverse chronological order and settled on chronological.

I tried one text file per month but would rather search a single file than a set of files.

I occasionally want images in my notebook. I put the images in the same directory and link to them using Markdown. I use the MarkView Chrome extension when I want to view the formatted document with the images inline.

Subject matter that is not chronological can go into separate text files in the same directory as the journal, one file per subject. You can link to them from the journal if necessary.


I wanted the same thing as you - the ability to do a journal, fully searchable, all text files. I also wanted to be able to cross reference things to create a sort of commonplace book without duplicating work. It took a lot of looking but I eventually found Wikidpad and have been using it ever since. It's really powerful.


Text files quickly become annoying when you have more than a few thousand.

I would write my journal into a MySQL database on my web space, create a simple PHP web interface to update, search and display entries, do more advanced operations in phpMySQL or through a direct SSH connection to the database server, and create a cronjob that will back it up in daily data dumps that get saved on the web server and emailed to me, with dumps older than 30 days automatically deleted. This way you have raw data that you can work on in any way to want, a one-file backup that you can open in any old text editor that reads plain text files, and you can create an interface that does everything you want and nothing more you don't need. You can export through PHP or Python or whatever you want into any format, from HTML to LaTeX to RTF, and you can easily re-arrange the different "sections" of your content (date, entry text, headline, keywords, etc.), if ever you think you want the date after the text instead of before it, as you wrote it in your text file.


I've kept journals in a variety of formats some that have gone obsolete, and I have settled on a big old .rtf as a reasonable solution.

I use a key combo to insert a date and time stamp so I don't even have to worry about the formatting.

The .rft format allows for some basic formatting that allows for some nuance.

When I go back and read a single file per year makes it very easy to read over that year, and the file size is more then small enough to be easy to store on all sorts of platforms.

One thing I find I sometimes have to do is add contextual details to old entries because I forgot why that was a big deal. If you weren't in the loop at the time someone reading it later just has no clue what it all means and why it was important to me.

I do need to do a better job tagging my images because they are important too so they can be related back to the context as well.


The answer completely depends on what you want to do with the files--how you want to access them in the future. Otherwise, organization doesn't matter.

Do you want to access them programmatically, using a program to read and operate on the text files? Open files manually, separately, and view them? Decide specifically how you want to access them later, and the organization should arise naturally from that.

You said you want to convert them using pandoc, but--what output? That's what I mean. Pandoc can manage whatever organization scheme you have.

Myself, I keep a journal in a single markdown file. Each #heading is a day's entry. Then, I can search a single file. I could easily do "one file a day", but I have no reason to.


I store everything as plaintext as a rule.

There has to be a good reason to use more sophisticated software.

I also keep my journal as one long text file, by year.

Using Linux, I could keep them as daily files and use the immensely powerful 'grep' or 'cat' functions to search or assemble all the files into one but I choose to keep the journal as one file.


Because it allows me to scan what I did yesterday and follow on a few of the key points to make the writing and thought process flow.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.