padUpload takes the file of one form field and stores it safely:

• its real type comes from its content - not from the type the browser claims, and not from its name - and is held against the types you allow, image/* for any image;
• a file over the size you allow, '2M', '500K' or bytes, is refused;
• it is stored under a random name in DATA/uploads/, with the extension of what it really is, never under the name the visitor's file had.

<?php

  $avatar = padUpload ( 'avatar', types: [ 'image/png', 'image/jpeg' ], max: '2M' );

  $said = $avatar ? 'Stored as ' . $avatar ['file'] : 'No picture was sent yet.';

?>

<p>{$said}</p>

{form 'picture'}
  {input 'avatar', type='file', label='Your picture'}
  <button>Upload</button>
{/form}

The answer is the record of the stored file - name (the visitor's own file name, for showing only), file (the path under DATA, for padFileGet), path, size, type and extension - or NULL when the field brought no file, or FALSE when the file was refused. padUploadError ( 'avatar' ) says why, and the {input} file field of the form shows it beside itself, in the words of its label.

A {form} holding a file field posts as multipart/form-data by itself; without that the browser sends only the file's name.

What is stored under DATA no address reaches. A page sends it back with padUploadSend ( $record ['file'], $record ['name'] ), which answers the file as the whole page and ends the request: its type read from its content again, a picture, a PDF or plain text shown, anything else - HTML, SVG, a script, which shown on the site's own address would run with its rights - downloaded; TRUE as its third argument downloads it in any case. A path out of DATA, or to no file, answers 404.