How to Get a Directory Tree in CMD as Shareable Text

The tree command in CMD draws a directory structure on the screen, yet that output rolls past as you scroll, may lose its box-drawing glyphs when pasted through a chat window, and offers no guarantee that two runs on the same folder will look identical once you copy them out. To get a directory tree in CMD that survives the trip into a README, issue, or code review as stable text, the reliable workflow is to dump a strict list of relative paths from the shell, feed that list into Directory Tree Generator, and pick the connector style that matches where the output will be pasted. The tool turns one relative path per line into a single displayed root with sorted branches, and the same accepted input always produces the same rendered output because ordering is by UTF-16 code units rather than by locale, modified date, or input order. Parsing, validation, sorting, rendering, and clipboard copy run in the current tab, so file names and folder structure never leave the machine that produced the list.

Why the built-in tree command falls short for shareable output

CMD's native tree command is designed for one consumer: the terminal you are sitting in front of. The default mode uses Unicode glyphs that some Windows consoles mishandle, and even when they render correctly the result is screen output, not a stable document. Switching to tree /A replaces those glyphs with +, -, and \ characters that survive most copy-paste routes, yet the underlying limitations remain.

• Sorting follows the underlying filesystem, which differs between NTFS, ReFS, exFAT, and network shares. Two runs of the same command on the same folder can produce visibly different orders.
• Indentation can shift between runs when child order changes at a given level, which makes diffs of generated trees noisy.
• Merging trees from multiple roots is not supported. tree walks one rooted path at a time.
• Glyphs do not always survive round-tripping through chat clients, email, or web forms. Even ASCII branch characters sometimes land in renderers that strip or replace them.
• There is no way to redact parts of the tree before publication without manual editing of an already-formatted block.

For a tree that ends up in a README, issue template, or pull request description, what you actually want is stable text whose columns line up the same way every time you regenerate it from the same source list. That goal sits one step upstream of tree, in a strict list of relative file paths.

When a path list beats running tree locally

There are real situations where running tree is the wrong starting point, even when CMD is open and ready.

• You do not have shell access on the target machine, but you do have a manifest, an export, or a paste from a colleague. A list of paths is the only input you can reach.
• You want to redact parts of the tree for a customer-facing document. Stripping names from a path list is faster and less error-prone than scrubbing an already-rendered tree.
• The folder you want to document lives on a different operating system, in a build artifact, or in a backup that is not mounted as a drive.
• You need deterministic output. A tree generated today from a clean path list will render byte-for-byte the same tomorrow, regardless of how the underlying filesystem decides to order directory entries.
• The tree is too deep for the terminal to display with clean indentation. The generator renders prefixes from a single dot root and stays within its output ceiling, so deep trees stay parsable instead of wrapping mid-glyph.

In each of these cases, the practical move is to skip CMD's tree and start from the path list directly.

Dumping a clean relative path list from CMD

1. Open CMD and change to the project root, for example cd "C:\Users\you\projects\demo".
2. To list files only, run dir /S /B /A-D. The /S flag recurses, /B strips headers and uses bare paths, and /A-D excludes directory entries so every line is a file.
3. To list files and folders together, run dir /S /B. Folder lines end without a trailing slash in bare format; file lines end with the file name.
4. Right-click the title bar, choose Mark, drag to select the block, press Enter to copy it to the clipboard.
5. Paste the block into a plain-text editor. Remove the leading absolute prefix from every line so each line is relative to the project root, for example by replacing C:\Users\you\projects\demo\ with nothing.
6. Confirm the separator style is consistent across every line. If any line uses forward slashes while the rest use backslashes, normalize the list before pasting into the tool.
7. Save the cleaned list. It should now look like a column of paths such as src\index.ts, src\components\Button.tsx, and README.md, separated by line feeds with no blank lines.

This list is the input the generator expects. Removing blanks, doubled separators, dot segments, and any absolute prefix at this stage prevents the most common rejection messages during generation.

Building the shareable tree with Directory Tree Generator

1. Open Directory Tree Generator in the same browser tab where you intend to copy the result. Nothing leaves the tab during parsing, sorting, rendering, or clipboard writing.
2. Paste the cleaned path list into the input area, one path per line, every line using the same separator style. Set the separator toggle to backslash for Windows-style paths or forward slash for POSIX-style paths.
3. Pick the connector style. Use Unicode (├──, └──, │) for GitHub, Notion, and modern Markdown viewers. Use ASCII (|--, `--, |) for terminals, code blocks behind strict filters, or wikis that strip non-ASCII characters.
4. Click Generate tree. The tool splits on line feed, removes a single trailing carriage return on each CRLF line, and rejects empty lines, duplicated paths, separators that do not match the toggle, dot segments, parent segments, absolute paths, and any line that crosses a segment or code-unit boundary.
5. Read the node count and the rendered tree. The output always begins with a single dot for the displayed root; directories appear before files at each level; siblings are ordered by UTF-16 code units.
6. Click Copy. The complete tree goes to the clipboard asynchronously. If the browser refuses clipboard permission, the rendered tree stays selectable so it can be copied manually with Ctrl+C or Cmd+C.
7. Paste the result into the README, issue template, architecture note, or code review. The connector style and ordering match what the tool produced, regardless of how the destination formatter lays out code blocks.

If a line is rejected, the tool reports the offending line number without dropping the rest of the input. Fix that line and click Generate again; no partial tree is ever produced.

Input rules the generator enforces

The limits are explicit, validation is strict, and a rejected input is never silently truncated. Knowing the exact rules prevents the most common surprises.

Constraint	Allowed value	Behavior at the boundary
Total input size	100,000 UTF-16 code units	Accepted on the limit; the next code unit rejects the run
Path lines	2,000 paths	The 2,001st line is rejected with its line number
Segments per path	128 segments	A 129th segment rejects that path
Segment length	255 UTF-16 code units	One more code unit rejects that segment
Rendered output	500,000 UTF-16 code units	Render aborts instead of truncating

Beyond the numeric ceilings, the tool refuses a list that contains a blank line (including a trailing blank line after the final entry), a path that mixes separators under one toggle, an absolute path, a leading separator, a Windows drive-root form, an empty segment from a doubled or trailing separator, a . or .. segment, an ASCII control character in a name, a duplicate exact path, a file/directory conflict, or a prefix conflict in either direction. Names with ordinary spaces and dots (such as .env.example, data file.json, archive.v1, and README draft.md) are preserved exactly as typed, and letter case is preserved as well, which is why Docs/readme.md and docs/readme.md are treated as two distinct entries.

Unicode vs ASCII branch characters

Both connector styles are valid for documenting a directory structure; the choice is about where the output will be rendered, not about what the tree represents.

• Unicode mode uses box-drawing characters: ├── for middle siblings, └── for the final sibling in a group, and │ for the vertical indent under parents. The result reads naturally in GitHub, GitLab, Bitbucket, Notion, Slack code blocks, and most modern Markdown viewers.
• ASCII mode uses ordinary keyboard characters: |--, `--, and |. The result reads reliably in terminals whose locale or font lacks box-drawing support, in pasted code blocks behind aggressive UTF-8 stripping, and in plain-text email or wiki rendering.

Switching between the two requires a fresh click on Generate tree. The tool clears any previous output as soon as the connector toggle moves, so an old tree cannot be mistaken for the current settings.

Privacy, sorting, and what the result actually represents

The generator is a deterministic text transformer, not a filesystem scanner. Knowing that shapes realistic expectations about what the output can and cannot say about the source project.

• Processing location. Parsing, validation, sorting, rendering, and clipboard writing all happen in the current browser tab. File names and folder structure are not uploaded to Lizely or sent to an external API.
• Sorting. Within each level, directories come first, and within the directory group and the file group, names are compared by UTF-16 code units. The ordering is deterministic across supported browsers and independent of locale, operating-system collation, input order, modification time, and filesystem metadata.
• Root convention. The output always begins with a single line containing a dot, the displayed root. Every child of that root is one segment deep, regardless of how the source paths were nested.
• Case sensitivity. Comparisons are exact JavaScript string compares, so Docs/readme.md and docs/readme.md remain distinct. If the same tree is later rendered on a case-insensitive filesystem such as NTFS, macOS HFS+, or APFS, the displayed ordering still matches what the generator produced.
• What the tool does not do. It does not read your disk, read folder metadata, verify that a path exists, label symlinks, calculate sizes, redact secrets, inspect ignore files, or compare the typed list with a real repository. Review the result before publishing; project trees can leak module names, customer names, or deployment layouts even when file contents are absent.

For a CMD-driven workflow, the final loop is straightforward: dump a clean relative path list, paste into Directory Tree Generator, pick a separator and connector style, generate, review the node count, and copy. That path covers the trip from the console output of tree to a stable, paste-ready directory tree in your documentation.