> ## Documentation Index > Fetch the complete documentation index at: https://docs.dify.ai/llms.txt > Use this file to discover all available pages before exploring further. # User Input > Collects user inputs to start workflow and chatflow applications ## Introduction The User Input node allows you to define what to collect from end users as inputs for your applications. Applications that start with this node run *on demand* and can be initiated by direct user interaction or API calls. You can also publish these applications as standalone web apps or MCP servers, expose them through backend service APIs, or use them as tools in other Dify applications. Each application canvas can contain only one User Input node. ## Input Variable ### Preset Preset input variables are system-defined and available by default. * `userinput.files`: Files uploaded by end users when they run the application. For workflow applications, this preset variable has been considered *legacy* and kept only for backward compatibility. We recommend using a [custom file input field](#file-input) instead to collect user files. * `userinput.query` (for chatflows only): The text message automatically captured from the user's latest chat turn. ### Custom You can configure custom input fields in a User Input node to collect different kinds of user input. Each field becomes a variable that can be referenced by downstream nodes. **Label Name** is displayed to your end users. If a field's value is something you already know (like a product identifier or tenant ID) and doesn't have to come from end users, mark it as **Hidden & Pre-Filled** and supply it yourself. See [Hide and Pre-Fill Input Fields](#hide-and-pre-fill-input-fields) for details. #### Text Input Accepts up to 256 characters. Use it for names, email addresses, titles, or any brief text input that fits on a single line. Allows long-form text without length restrictions. It gives users a multi-line text area for detailed responses or descriptions. #### Structured Input Displays a dropdown menu with predefined options. Users can choose only from listed options, ensuring data consistency and preventing invalid inputs. Restricts input to numerical values only—ideal for quantities, ratings, IDs, or any data requiring mathematical processing. Provides a simple yes/no option. When a user checks the box, the output is `true`; otherwise, it's `false`. Use it for confirmations or any case that requires a binary choice. Accepts data in JSON object format, ideal for passing complex, nested data structures into your application. You can optionally define a JSON schema to validate the input and guide end users on the expected structure and validation requirements. This also allows you to reference individual properties of the object in other nodes. #### File Input Allows users to upload one file of any supported type, either from their device or via a file URL. The uploaded file is available as a variable containing file metadata (name, size, type, etc.). Supports multiple file uploads at once. It's useful for handling batches of documents, images, or other files together. Use a List Operator node to filter, sort, or extract specific files from the uploaded file list for further processing. **File Processing** Since the User Input node only collects files—it does not read or parse their content—uploaded files must be processed appropriately by subsequent nodes. For example: * Document files can be routed to a Doc Extractor node for text extraction so that LLMs can understand their content. * Images can be sent to LLM nodes with vision capabilities or specialized image processing tool nodes. * Structured data files such as CSV or JSON can be processed with Code nodes to parse and transform the data. When users upload multiple files with mixed types (e.g., images and documents), you can use a List Operator node to separate them by file type before routing them to different processing branches. ## Hide and Pre-Fill Input Fields Sometimes the workflow needs an input you already know, and asking end users to type it would be friction. Mark such a field as **Hidden & Pre-Filled**: you supply the value, end users never see the field, and the workflow still receives it. Imagine your company runs landing pages for many different products, each featuring an AI chatbot. The workflow behind every chatbot is essentially the same; only the product identifier differs. Rather than maintain a separate workflow per product, you keep just one (with a hidden `productName` field) and pre-fill a different value on each landing page. End users perceive each page as having its own product-specific chatbot, but behind the scenes, every page passes a different `productName` into the same workflow. Hidden fields are **not secret**. Values travel in the URL query string and are visible in the browser address bar, browser history, and network traffic. For credentials and API keys, use [Environment Variables](/en/use-dify/getting-started/key-concepts#variables) instead. Single File and File List fields do not support this feature. 1. In the **Edit Input Field** window, uncheck **Required** if it's checked. These two options are mutually exclusive. 2. Check **Hidden & Pre-Filled**. Optionally set a default value as a fallback when no value is pre-filled at runtime. Hidden fields still appear in the **Preview** panel so you can test the flow without publishing. 1. Publish your app. 2. Choose the method that fits how your end users reach the app. Use this when end users open the WebApp directly from its link. 1. In the app's publishing panel, within the **Web App** section, click the gear icon next to **Launch**. Hidden Fields Pre-Fill Icon 2. Fill in the hidden fields and click **Launch**. The WebApp opens with your values applied as URL query parameters; copy the URL from the address bar to share. **To generate many links with different values**, use the same pattern to write more yourself, or have a system fill in the values automatically: ```text wrap theme={null} {WEBAPP_URL}?{VARIABLE_NAME}={VALUE}&{VARIABLE_NAME}={VALUE} # Example: https://udify.app/chat/abc123?productName=Acme®ion=us-east ``` URL-encode any values that contain spaces or special characters (for example, `Acme Corp` becomes `Acme%20Corp`). A support team using a CRM can add `?customerId={{customer.id}}` to the end of the WebApp URL in their ticket-response templates. The CRM substitutes the real customer ID when the rep sends the link, so the chatbot knows which customer it's talking to without having to ask. Use this when the app is embedded as an iframe or script on your site. Use this when every visitor should receive the same values (a site-wide region, the embedded page's product ID, etc.). 1. In the app's publishing panel, within the **Web App** section, click **Embedded** > **Pre-Fill Hidden Fields**. Embedded Icon 2. Fill in the hidden fields. Entered values are baked into the iframe URL and the `inputs` object of the script snippet. Use this when each visitor should receive their own values (the logged-in user's ID, the page they're on, etc.). In the embed snippet on your site, set each hidden field as a key in the `inputs` object of `window.difyChatbotConfig`. Each value is computed at render time from your site's context, so every visitor gets their own. ```html theme={null} ```