I think it might be useful to make file path edit box in my program multi line, because file paths can be quite long, and when they don't fit the user has to scroll text left and right with cursor keys.

Are there any cons to doing a multi-line input in this case?

  • What's the platform? Commented Apr 23, 2015 at 11:26
  • @DarrylGodden, Windows. Does this matter?
    – user626528
    Commented Apr 23, 2015 at 11:32
  • Console user might not be bothered by scrolling with cursor keys.
    – Yohann V.
    Commented Apr 23, 2015 at 12:14
  • … and other users should not be bothered with file paths usually.
    – Crissov
    Commented Apr 23, 2015 at 13:29
  • Why are they editing the path and does anything happen with it when they are finished? Is it displayed back to them on screen? Commented Apr 23, 2015 at 13:34

5 Answers 5


In response to your comments my answer is this.

If it improves the user experience to be able to see and edit the file name and path by breaking it over multiple lines then I would suggest its sensible to do so.

As long as you keep in mind accuracy.

Perhaps a better suggestion would be to breakdown the file path into it's constituent parts and allow users to select the path from prompts or, perhaps even better, to use an explorer dialogue to allow them to browse to the correct path.


Yes, it make sense

...if the only other choice is a 1-line input box.

One line input boxes are terrible for editing long text (i.e. significant box overflow), for reasons that are almost completely obvious. They're bad on the web and even worse on tablets or mobile phones.

If you have no other way to create space for the long paths, then a multi-line textbox will work better than a 1-line input box. An expanding textbox is better than a fixed-height textbox.

Here is an example of the expanding textbox for editing file names in Windows 8:

enter image description here

Here, Microsoft could have provided more horizontal space or a pop-up edit box, but they likely decided that the benefits of "in-flow", inline editing even with the awkward text wrapping outweighed the costs of providing out-of-flow edit boxes.

  • Your example shows labels, not file paths. Multi-line is fine for most text, but paths are sensitive to white space, among other things that are error prone across line breaks. Commented Apr 24, 2015 at 6:36
  • one line input boxes are even more error prone!
    – tohster
    Commented Apr 24, 2015 at 6:43

If there is a special interraction with this file path that start a special event in your application, you may make it larger.

The multi-line choice can be confusing if the path is totally filled :


So I do not recommend to make it multiline.

If it is a common file path, moreover next to Browse, make it one line and aligned with the rest of the content.

  • Confusing? Why?
    – user626528
    Commented Apr 23, 2015 at 16:53
  • @user626528 edited
    – Yohann V.
    Commented Apr 24, 2015 at 6:32

If you're going to allow users to place long paths, I would opt for a paste button of the sort. (make sure they can paste a long path in the text box). In many years using windows I don't remember many times where ctrl+v has failed me.


Don’t break file paths

It opens up too much room for error. The same goes for URLs. Yes, it can be done, but I've never encountered a scenario where a better solution didn't exist.

If your user is highly technical, they'll be familiar with long file paths. In my experience, they will prefer keeping it all on one line. They'll be comfortable with a command line like entry because it will build a sense of confidence.

If you are addressing a typical user, they won't be familiar with long paths at all, whether on one line or many. They want to see some kind of file browser that inserts the name of the selected file in the UI. Don't make them look at the path at all.

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.