Jupyter Notebook output truncation limit across classic and JupyterLab

Short answer

Jupyter Notebook 7.x does not enforce a separate classic-interface truncation limit. Notebook 7.x is built on JupyterLab, so stdout and stderr are rendered in a scrollable output area without character-level truncation. The legacy classic frontend (notebook 6.x and earlier) truncated long text output client-side and offered an expand control, but that behavior does not apply to 7.x. NotebookApp.truncated_output_size is not confirmed as an enforced trait in 7.x; verify it in your installed version before relying on it.

Confirmed versus unverified

Statement	Status	Notes
Legacy classic Notebook (<=6.x) truncates long text output client-side with an expand affordance	Confirmed	Truncation lives in the output-area JavaScript, not in themes; the exact threshold varies by version.
JupyterLab and Notebook 7.x show full output in a scrollable area with no character cap	Confirmed	Output remains in the DOM; CSS controls visible height and scrollbars only.
NotebookApp.truncated_output_size is enforced in Notebook 7.x	Unverified	Server-side size controls are IOPub rate limits and Tornado message/buffer limits, which drop or reject messages rather than truncate characters.
Frontend themes remove characters from output in 7.x	Not supported	Themes can clip or scroll visually, but they do not delete characters from rendered output.

Verification steps

1. Check whether the trait is registered in your server:

   jupyter notebook --help-all | grep -i truncated_output_size

   No output means the option does not exist in this installation.
2. Inspect the generated config file:

   jupyter notebook --generate-config
   grep -R "truncated_output_size" ~/.jupyter/jupyter_notebook_config.py

3. Render a known-large output and measure the DOM element. In a notebook cell:

   import sys
   text = "x" * 100000
   print(text, file=sys.stdout)
   print(text, file=sys.stderr)

   Open browser developer tools, inspect the output element, and compare scrollHeight with clientHeight. Full text length with a scrollbar indicates scrolling, not truncation.
4. If output is missing with a warning, check kernel-side rate limits:

   jupyter notebook --help-all | grep -i iopub

   Review iopub_data_rate_limit and iopub_msg_rate_limit; these can drop large output independent of the frontend.

One missing diagnostic detail

What is the exact installed version of notebook (and jupyterlab, if present)? If you are running notebook 6.x with the legacy classic frontend, client-side truncation may still apply. On 7.x, the Lab-based scrolling behavior applies instead.

Practical consequence

Do not assume a default ~1000-character cap on stdout/stderr in JupyterLab or Notebook 7.x. Long output is fully present in the DOM and only visually scrolled. If output appears missing, investigate IOPub rate limiting or HTTP/WebSocket message size limits before concluding that the frontend truncated it.