Notebooks are where analysis, model results and research findings first appear. If you later need to show that a result, a model or a method existed before a paper, a competitor’s announcement or an allegation of misconduct, the notebook is the natural evidence. Here is what an .ipynb file records, why its timing is weak, and what to freeze so the date can be checked.
Short answer: Notebook files carry no trustworthy date, and Git commit dates come from your own machine. To show a result or method existed before a paper or announcement, save the .ipynb with its outputs and the data it used, and timestamp them with TimeBinder. A TimeBind shows that the exact file existed no later than the recorded time and still matches its fingerprint. It doesn’t show who made it or what a court will make of it.
Disclosure: I’m Inna Hall, co-founder of TimeBinder, the file timestamping tool this guide uses. This page is general information, not legal advice.
Table of Contents
What a notebook records
- The .ipynb file is JSON: code and markdown cells, their outputs (including images as embedded data), execution counts and metadata such as the kernel and language version.
- No creation date by default. The format does not store when a notebook was created or when each cell ran. Execution counts show order only.
- Optional timing metadata. Some Jupyter settings and extensions record when cells ran, using the machine’s clock.
- Platform history. Colab notebooks live in Google Drive with its revision history; JupyterHub and cloud notebooks may keep checkpoints.
Why that is easy to challenge
Everything in the file can be edited as text, and any timing data comes from the machine that ran it. Results also depend on things outside the notebook: the data, the library versions and sometimes random seeds. A notebook alone shows the code; it does not pin down the data or environment that produced the outputs, or when.
What to freeze
- The notebook with outputs, exactly as it was when you got the result.
- An HTML or PDF export, so a reviewer can read the outputs without running anything.
- The environment: requirements.txt, environment.yml or a lock file.
- The data, or for large datasets a SHA-256 manifest listing each file’s hash. The free SHA-256 file hash checker shows the hash of any file.
- Model weights or result files if the claim is about a trained model or a benchmark score.
A simple routine
- When you reach a result worth keeping, save the notebook and export it to HTML.
- Save the environment file and, if needed, write a hash manifest for the data.
- TimeBind the notebook, export, environment file and manifest together in TimeBinder (up to 10 files in one Pooled TimeBind).
- Commit or archive the same files unchanged, and keep the certificate with them. If you strip outputs in Git, keep the timestamped copy with outputs separately.
Which plan fits
The free plan gives you 1 Token a month, which is one Pooled TimeBind of up to 10 files. No credit card is required for the free plan. A Pooled TimeBind is usually recorded within 24 to 48 hours, and often sooner, depending on Bitcoin network activity; an ASAP TimeBind costs 3 Tokens and gets its own Bitcoin transaction straight away.
For more milestones, Essential is US$20 a month for 5 Tokens (5 Pooled, or 1 ASAP plus 2 Pooled). Expert is US$50 a month for 15 Tokens (15 Pooled or 5 ASAP), and unused Tokens roll over. Verification is free. See pricing.
What a timestamp does and doesn’t do
TimeBinder anchors each file’s SHA-256 fingerprint to Bitcoin and gives you a Proof of Time Certificate. That is verifiable evidence of when a file existed: it shows the file existed no later than the anchor date, and any later change to the file is detectable. An ASAP TimeBind can be checked directly on the Bitcoin blockchain without relying on TimeBinder; a Pooled TimeBind is verified through TimeBinder. Your file is hashed in your browser and never uploaded.
It doesn’t show who made the work or who owns it, it doesn’t stop copying, and it doesn’t cover a version you didn’t timestamp. It also doesn’t show that a result is correct or reproducible. For code repositories, see Git commit dates as proof and how to prove source code existed before a date. For lab notes, datasets and drafts beyond notebooks, see our guide to blockchain timestamping for academic research.
Frequently Asked Questions
Does a Jupyter notebook store when it was run?
Not by default. An .ipynb file is JSON with cells, outputs and metadata such as the kernel. Execution counts show order, not time. Some settings and extensions add execution times to cell metadata, but those come from your machine and can be edited like any JSON.
Why did my notebook’s fingerprint change when I didn’t edit the code?
Re-running cells changes outputs and execution counts, and clearing outputs changes the file too. Tools that strip outputs before a Git commit mean the committed file differs from the one on disk. Timestamp the exact file you want to rely on.
My dataset is too big to timestamp easily. What can I do?
Make a manifest: a text file listing the SHA-256 hash of each data file. TimeBind the manifest with the notebook. Later anyone can re-hash the data and compare it with the manifest.
Is Git enough for notebooks?
Git shows order and content, but commit dates are set by the committer. Anchoring a commit ID or the notebook file with a timestamp gives a date others can check.
Plan details were checked against timebinder.io/pricing on 29 October 2026.
