A directory tree generator converts one complete relative file path per line into a rendered text tree whose root is a single dot and whose parent directories are inferred from shared prefixes. The process is local: you paste the paths, pick the separator style you used (forward slash or backslash), choose Unicode or ASCII connectors, and the tool returns a deterministic tree that you can copy into a README, ticket, or design document. Because validation, sorting, and rendering happen in the current browser tab, the file names and project structure you paste never leave your machine. The output is identical across supported browsers because name order is set by UTF-16 code-unit comparison rather than locale, filesystem, or input order. Strict validation is what makes that determinism trustworthy. The generator rejects absolute paths, drive roots, mixed separators, empty segments, dot segments, parent traversal, duplicate paths, and file/directory conflicts rather than silently rewriting them, and the exact limits are 100,000 UTF-16 code units of input, 2,000 path lines, 128 segments per path, 255 code units per segment, and 500,000 code units of rendered output, with the next unit, entry, segment, or output character beyond any boundary rejected with an error message that points at the offending line.
From a List of Paths to a Visual Tree
A directory tree turns a flat enumeration of files into a structure a reader can scan at a glance. Most developers reach for a tree when they need to communicate the shape of a module, attach evidence to a bug report, or sketch the layout of a new package before any code is written. The fastest path to that tree is often a one-line shell command, but shell commands assume you have read access to the folder you want to print, and they frequently mix structure and file content or rely on a terminal that may not render box-drawing characters.
A browser-based generator takes a different route. You supply a list of relative paths, the tool interprets them as a single in-memory prefix tree, and you receive the rendered output back as plain text. The list can come from anywhere: a pasted find output, a directory listing copied from a file manager, a CSV export, or a hand-written draft of a proposed layout. The only structural constraint is that every line is a complete relative path and that all lines use the same separator style.
Prepare Your Path List
The quality of the tree is set by the quality of the input. Before you paste, walk through four small checks that catch most rejections.
First, confirm that every line is a complete relative file path. A path is relative when it has no leading separator and no drive root. src/lib/parser.ts is relative; /src/lib/parser.ts and C:\src\lib\parser.ts are not. The generator treats absolute and drive-root forms as errors instead of silently rewriting them.
Second, decide which separator style the list uses and stick to it. Forward slashes are the universal default and match Unix, macOS, and most modern tooling. Backslashes are common in Windows-native paths such as src\lib\parser.ts. Mixing src/lib/parser.ts and src\lib\parser.ts in the same run is rejected because the tool cannot tell which separator was intended at any given position.
Third, strip stray blank lines, leading or trailing whitespace, and any carriage returns left over from a Windows paste. A bare carriage return is treated as an ASCII control character, and a blank line is treated as an empty path; both fail validation.
Fourth, make sure every name represents a file rather than a directory declaration. The list src followed by src/index.ts is an explicit file/directory conflict, because the first line says there is a file named src and the second line says there is a directory named src. If you want a directory, list a file inside it; the parent is inferred from the prefix.
Generate the Tree in Three Steps
Open the Directory Tree Generator and follow three explicit steps.
- Paste one complete relative file path per line in the input box. Confirm that every line uses the same separator style and that there are no blank lines, stray carriage returns, leading separators, drive roots, dot segments, or mixed separators anywhere in the list.
- Pick the separator that matches your input (forward slash or backslash) and the output style (Unicode or ASCII connectors). The separator setting is strict; the opposite separator anywhere in the input is rejected rather than silently converted.
- Select Generate tree. The page clears any prior tree or error, validates the list against the explicit limits, renders the tree starting from a single dot, and shows a count of the nodes created. Copy the rendered output with the Copy action or select the text manually if clipboard permission is unavailable.
A successful run reports the node count and the rendered tree. If the input exceeds 2,000 lines, 100,000 UTF-16 code units, 128 segments per path, or 255 code units per segment, the offending line is reported and the previous successful tree is removed so nothing stale remains visible. A failed generation never leaves an older successful tree on the page.
Choosing Between Unicode and ASCII Output
The generator offers two connector styles that produce the same structure but render it differently. The choice is purely cosmetic and does not affect ordering, validation, or the inferred directory hierarchy.
| Aspect | Unicode mode | ASCII mode |
|---|---|---|
| Branch connectors | ├── and └── | |-- and `-- |
| Vertical guides | │ | | |
| Best environment | Modern editors, web documentation, terminals with UTF-8 | Plain-text environments, terminals without UTF-8, copy-paste into legacy systems |
| Visual density | Compact, recognizable in Markdown rendering | Slightly wider, made entirely of keyboard characters |
| Sort order and structure | Identical to ASCII | Identical to Unicode |
Switching the connector style does not regenerate the tree on its own. The page clears the existing output the moment the setting changes and waits for a fresh Generate tree action, so the output you see always reflects the current combination of separator and connector settings.
Why the Generator Rejects Ambiguous Input
Strict validation is the core of a deterministic generator. The tool rejects every input that could produce two different trees for the same input, or that could quietly change the meaning of a path behind your back. The most common rejection reasons fall into a short list.
| What the input contains | Why it is rejected |
|---|---|
| Mixed separators (for example src/lib\parser.ts) | The separator setting is strict, and the opposite separator is not guessed or replaced. |
| Empty segments from doubled or trailing separators (src//index.ts, src/) | Empty segments are not normalized away. |
| Dot or parent segments (./src/index.ts, ../index.ts) | The generator does not rewrite traversal paths. |
| Absolute paths or drive roots (/home/user/src/index.ts, C:\src\index.ts) | Relative paths are required. |
| Duplicate paths | Silent deduplication would change the meaning of the input. |
| File/directory conflict (src plus src/index.ts) | The same line cannot sometimes mean a file and sometimes a directory. |
| ASCII control characters, including a bare carriage return | They can split terminal output or render the tree misleading. |
| Blank line, including a trailing blank line | An empty path is not a valid file path. |
Every rejection points at a specific line. The tool does not skip the bad line, return a partial tree, or truncate names, segments, or output to fit a quota. The limits are explicit: at most 100,000 UTF-16 code units of input, at most 2,000 path lines, at most 128 segments per path, at most 255 code units per segment, and at most 500,000 code units of rendered output. The exact boundary value is accepted; the next unit, entry, segment, or output character is not.
Where a Generated Tree Fits in Your Workflow
- READMEs and onboarding: A short tree at the top of a README gives a new contributor the shape of the project in seconds. Because the generator sorts by UTF-16 code units rather than input order, you can reorder the source list without changing the rendered result, which keeps the tree stable across edits.
- Issue reports and bug tickets: When a bug report needs the exact files involved, a pasted tree is more compact and harder to misinterpret than a prose list. Reviewers can see at a glance which module the path belongs to and which leaves are siblings.
- Code reviews and pull-request descriptions: A generated tree of the touched files summarises a change without dragging in unrelated directories. Because duplicate paths are rejected, the list itself documents the unique files in the change.
- Architecture notes and design memos: Architecture notes benefit from trees that match the proposed layout exactly. The strict validation catches any drift between the prose and the list, because the generator refuses to render an inconsistent input.
- Support and customer messages: When a support engineer needs to confirm a customer's directory layout, a tree generated from a short path list travels well through chat, ticket forms, and email without revealing file contents. The generator never inspects a local folder, so the customer controls exactly which paths are shared.
For Windows users who gather paths through a command shell before pasting, the CMD walkthrough for directory trees covers the command-line side of the same task. Linux and macOS users can find the equivalent shell pipeline in the Linux path-list guide.
The same list, the same settings, and the same browser environment produce the same tree every time, so a tree generated today stays stable when a colleague regenerates it from a slightly reordered source list tomorrow. That determinism is what makes a directory tree generator a practical primitive for documentation: paste, generate, copy, paste again when the layout changes.